Also implements explicit handling for the already-documented --help
flag.

Reviewed By: frasercrmck

Differential Revision: https://reviews.llvm.org/D122369

This flag silents the build output of test-release.sh so that
it can be used in CI systems a bit better. It will still log
the build output to the log files but not echo it to stdout.

Reviewed By: tstellar

Differential Revision: https://reviews.llvm.org/D122146

Move to clang_ignored_gcc_optimization_f_Group like other ignored options. This
decreases code size a bit: ~400 bytes on x86-64.

A new function 'getConstrainedIntrinsic' is added, which for any gived
instruction returns id of the corresponding constrained intrinsic. If
there is no constrained counterpart for the instruction or the instruction
is already a constrained intrinsic, the function returns zero.

This is recommit of 115b3ace, reverted in
8160dd58.

Differential Revision: https://reviews.llvm.org/D69562

This patch constructs codegen infra and successfully generate the first
'add' instruction. Add integer calling convention for fixed arguments which
are passed with general-purpose registers.

New test added here:

  CodeGen/LoongArch/ir-instruction/add.ll

The test file is placed in a subdirectory because we will use
subdirctories to distinguish different categories of tests (e.g.
 intrinsic, inline-asm ...)

Reviewed By: MaskRay, SixWeining

Differential Revision: https://reviews.llvm.org/D122366

in filesystems

It is simpler to search for module unit by -fprebuilt-module-path
option. However, the separator ':' of partitions is not friendly.
According to the discussion in https://reviews.llvm.org/D118586, I think
we get consensus to use '-' as the separator instead. The '-' is the
choice of GCC too.

Previously I thought it would be better to add an option. But I feel it
is over-engineering now. Another reason here is that there are too many
options for modules (for clang module mainly) now. Given it is not bad
to use '-' when searching, I think it is acceptable to not add an
option.

Reviewed By: iains

Differential Revision: https://reviews.llvm.org/D120874

According to the LLVM debug info update guide: https://llvm.org/docs/HowToUpdateDebugInfo.html,
"Hoisting identical instructions which appear in several successor
blocks into a predecessor block. In this case there is no single
merged instruction. The rule for dropping locations applies".

Thanks to Yuanbo Li for reporting this.

Reviewed By: dblaikie

Reviewers: sebpop, tejohnson, dblaikie

Differential Revision: https://reviews.llvm.org/D122730

For example, we could do the following eliminations:
  fold vector.shuffle V1, V2, [0, 1, 2, 3] : <4xi32>, <2xi32> -> V1
  fold vector.shuffle V1, V2, [4, 5] : <4xi32>, <2xi32> -> V2

Differential Revision: https://reviews.llvm.org/D122706

A format such as "( D   C, X6. 2  )" is parsed the same as "(DC,X6.2)".

NSIndexPathSyntheticFrontEnd::Impl::Clear() currently calls Clear() on both
unions members regardless of which one is active. I modified it to only call
Clear() on the active member.

Differential Revision: https://reviews.llvm.org/D122753

This lets the revert_checker.py get called with the -u option, which
formats the revert and reverted SHAs into handy URLs which point to the
LLVM reviews associated with those SHAs. This is useful for viewers to
look quickly at the changes made by SHAs that were potentially reverted.

Differential Revision: https://reviews.llvm.org/D122772

Factor in the TBAA of adjacent stores instead of just the head store
when merging stores into a memset. We were seeing GVN remove a load that
had a TBAA that matched the 2nd store because GVN determined it didn't
match the TBAA of the memset. The memset had the TBAA of only the first
store.

i.e. Loading the field pi_ of shared_count after memset to create an
array of shared_ptr

template<class T>
class shared_ptr {
  T *p;
  shared_count refcount;
};

class shared_count {
  sp_counted_base *pi_;
};

Differential Revision: https://reviews.llvm.org/D122205

Beautify dump format, add indent for nested struct and struct members, also fix test cases in dump-struct-builtin.c
for example:
struct:
```
  struct A {
    int a;
    struct B {
      int b;
      struct C {
        struct D {
          int d;
          union E {
            int x;
            int y;
          } e;
        } d;
        int c;
      } c;
    } b;
  };
```
Before:
```
struct A {
int a = 0
struct B {
    int b = 0
struct C {
struct D {
            int d = 0
union E {
                int x = 0
                int y = 0
                }
            }
        int c = 0
        }
    }
}
```
After:
```
struct A {
    int a = 0
    struct B {
        int b = 0
        struct C {
            struct D {
                int d = 0
                union E {
                    int x = 0
                    int y = 0
                }
            }
            int c = 0
        }
    }
}
```

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D122704

Improve the performance of expm1f:
- Rearrange the selection logic for different cases to improve the overall
throughput.
- Use the same degree-4 polynomial for large inputs as `expf`
(https://reviews.llvm.org/D122418), reduced from a degree-7 polynomial.

Performance benchmark using perf tool from CORE-MATH project
(https://gitlab.inria.fr/core-math/core-math/-/tree/master):
Before this patch:
```
$ ./perf.sh expm1f

CORE-MATH reciprocal throughput   : 15.362
System LIBC reciprocal throughput : 53.288
LIBC reciprocal throughput        : 54.572

$ ./perf.sh expm1f --latency

CORE-MATH latency   : 57.759
System LIBC latency : 147.146
LIBC latency        : 118.057
```

After this patch:
```
$ ./perf.sh expm1f

CORE-MATH reciprocal throughput   : 15.359
System LIBC reciprocal throughput : 53.188
LIBC reciprocal throughput        : 14.600

$ ./perf.sh expm1f --latency

CORE-MATH latency   : 57.774
System LIBC latency : 147.119
LIBC latency        : 60.280

```

Reviewed By: michaelrj, santoshn, zimmermann6

Differential Revision: https://reviews.llvm.org/D122538

[clang-format] Indent import statements in JavaScript.

Take for example this piece of code found at
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import>.

```
for (const link of document.querySelectorAll("nav > a")) {
  link.addEventListener("click", e => {
    e.preventDefault();

    import('/modules/my-module.js')
        .then(module => {
          module.loadPageInto(main);
        })
        .catch(err => {
          main.textContent = err.message;
        });
  });
}
```

Previously the import line would be unindented, looking like this.

```
for (const link of document.querySelectorAll("nav > a")) {
  link.addEventListener("click", e => {
    e.preventDefault();

import('/modules/my-module.js')
        .then(module => {
          module.loadPageInto(main);
        })
        .catch(err => {
          main.textContent = err.message;
        });
  });
}
```

Actually we were going to fix this along with fixing Verilog import
statements.  But the patch got too big.

Reviewed By: MyDeveloperDay, curdeius

Differential Revision: https://reviews.llvm.org/D121906

Currently, when creating a target for a fat binary, we error out if more
than one platforms can support the different architectures in the
binary. There are situations where it makes sense for multiple platforms
to support the same architectures: for example the host and
remote-macosx platform on Darwin.

The only way to currently disambiguate between them is to specify the
architecture. This patch changes that to take into account the selected
and host platform. The new algorithm works a follows:

1. Pick the selected platform if it matches any of the architectures.
2. Pick the host platform if it matches any of the architectures.
3. If there's one platform that works for all architectures, pick that.

If none of the above apply then we either have no platform supporting
the architectures in the fat binary or multiple platforms with no good
way to disambiguate between them.

I've added a bunch of unit tests to codify this new behavior.

rdar://90360204

Differential revision: https://reviews.llvm.org/D122684

This reverts commit 5630143a. The
implementation in this commit was incorrect. Also, handling this representation
of equalities in the upcoming support for symbolic lexicographic minimization
makes that patch much more complex. It will be easier to review that without
this representaiton and then reintroduce the fixed column representation
later, hence the revert rather than a bug fix.

Instead of looking up the vector loop using the header, keep track of
the current vector loop in VPTransformState. This removes the
requirement for the vector header block being part of the loop up front.

A follow-up patch will move the code to generate the Loop object for the
vector loop to VPRegionBlock.

Depends on D121619.

Reviewed By: Ayal

Differential Revision: https://reviews.llvm.org/D121621

Differential Revision: https://reviews.llvm.org/D122715

Differential Revision: https://reviews.llvm.org/D122710

Sometimes we would like to run post-processing repeatedly on the original sample profile for tuning. In order to avoid regenerating the original profile from scratch every time, this change adds the support of reading in the original profile (called symbolized profile) and running the post-processor on it.

Reviewed By: wenlei

Differential Revision: https://reviews.llvm.org/D121655

When two local symbols (think: file-scope static functions, or functions in
unnamed namespaces) with the same name in two different translation units
both needed thunks, ld64.lld previously created external thunks for both
of them. These thunks ended up with the same name, leading to a duplicate
symbol error for the thunk symbols.

Instead, give thunks for local symbols local visibility.

(Hitting this requires a jump to a local symbol from over 128 MiB away.
It's unlikely that a single .o file is 128 MiB large, but with ICF
you can end up with a situation where the local symbol is ICF'd with
a symbol in a separate translation unit. And that can introduce a
large enough jump to require a thunk.)

Fixes PR54599.

Differential Revision: https://reviews.llvm.org/D122624

Add it to the toctree for the LLVM command guide.

This reverts commit bdea2afc.

Bot failure.

Add documentation describing how to

- Use `llvm-remark-size-diff`
- Interpret the output from the tool

Differential Revision: https://reviews.llvm.org/D122744

Use the setter in BOLT to allow printing names with variant kind in the name
(e.g. "func@PLT").
Fixes BOLT buildbot tests that broke after D122516:
https://lab.llvm.org/buildbot/#/builders/215/builds/3595

Reviewed By: maksfb

Differential Revision: https://reviews.llvm.org/D122694

This was triggering some build failures so removing this change for now.

Currently, we have two different lists of features each CPU supports...
and those lists aren't consistent. This patch assumes AArch64.td is
right, and tries to fix AArch64TargetParser to match.

It's hard to find documentation for the right features, but reviewers
have confirmed these changes.

Probably we should try to unify the two lists at some point, but
synchronizing them seems like a prerequisite to that anyway.

Differential Revision: https://reviews.llvm.org/D122274

Updating the diagnostics as per the feedback on
https://reviews.llvm.org/D122627.

This change correctly handles missing argument lists, and changes the
subject for the `numthreads` attribute to be global functions.

I did not handle applying the attribute to template functions because
that currently fails parsing in a way that is consisetent with the
current DXC codebase (Microsoft attributes are not supported on
templates).

A future improvement to the diagnostic maybe warranted.

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

Differential Revision: https://reviews.llvm.org/D122506

If the `ExternalFS` has already remapped a path then the
`RedirectingFileSystem` should not change it to the originally provided
path. This fixes the original path always being used if multiple VFS
overlays were provided and the path wasn't found in the highest (ie.
first in the chain).

This also renames `IsVFSMapped` to `ExposesExternalVFSPath` and only
sets it if `UseExternalName` is true. This flag then represents that the
`Status` has an external path that's different from its virtual path.
Right now the contained path is still the external path, but further PRs
will change this to *always* be the virtual path. Clients that need the
external can then request it specifically.

Note that even though `ExposesExternalVFSPath` isn't set for all
VFS-mapped paths, `IsVFSMapped` was only being used by a hack in
`FileManager` that was specific to module searching. In that case
`UseExternalNames` is always `true` and so that hack still applies.

Resolves rdar://90578880 and llvm-project#53306.

Differential Revision: https://reviews.llvm.org/D122549

Previously, these isel optimizations were disabled if the AND could
be selected as a ANDI instruction. This patch disables the optimizations
only if the immediate is valid for C.ANDI. If we can't use C.ANDI,
we might be able to compress the shift instructions instead.

I'm not checking the C extension since we have relatively poor test
coverage of the C extension. Without C extension the code size
should be equal. My only concern would be if the shift+andi had
better latency/throughput on a particular CPU.

I did have to add a peephole to match SRLIW if the input is zexti32
to prevent a regression in rv64zbp.ll.

Reviewed By: luismarques

Differential Revision: https://reviews.llvm.org/D122701

Differential Revision: https://reviews.llvm.org/D121853