This makes the default build closer to a -DLLVM_ENABLE_RUNTIMES=all build.
The layout is arguably superior because different libraries of target triples
are in different directories, similar to GCC/Debian multiarch.

When LLVM_DEFAULT_TARGET_TRIPLE is x86_64-unknown-linux-gnu,
`lib/clang/14.0.0/lib/libclang_rt.asan-x86_64.a`
is moved to
`lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a`.

In addition, if the host compiler supports -m32 (multilib),
`lib/clang/14.0.0/lib/libclang_rt.asan-i386.a`
is moved to
`lib/clang/14.0.0/lib/i386-unknown-linux-gnu/libclang_rt.asan.a`.

Clang has been detecting both paths for lib/Driver/ToolChains/Gnu.cpp since 2018 (D50547).

---

Note: Darwin needs to be disabled. The hierarchy needs to be sorted out.
The current -DLLVM_DEFAULT_TARGET_TRIPLE=off state is like:
```
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_ios.a
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_iossim.a
lib/clang/14.0.0/lib/darwin/libclang_rt.profile_osx.a
```

Windows needs to be disabled: https://reviews.llvm.org/D107799?id=368557#2963311

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

9ee64c37 has started using
COMPILER_RT_HAS_OMIT_FRAME_POINTER_FLAG inside scudo.  However,
the relevant CMake check was performed in builtin-config-ix.cmake,
so the definition was missing when builtins were not built.  Move
the check to config-ix.cmake, so that it runs unconditionally of
the components being built.

Fixes PR#51847

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

Updated check lines.
Tests precommitted from D109700.

On x86_64-unknown-linux-gnu, `-m32` tests set LD_LIBRARY_PATH to
`config.compiler_rt_libdir` (`$build/lib/clang/14.0.0/lib/x86_64-unknown-linux-gnu`)
instead of i386-unknown-linux-gnu, so `-shared-libsan` executables
cannot find their runtime (e.g. `TestCases/replaceable_new_delete.cpp`).

Detect -m32 and -m64 in config.target_cflags, and adjust `config.compiler_rt_libdir`.

Reviewed By: vitalybuka

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

Summary:

Reviewers:

Subscribers:

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

same/alternate instructions.

Some setjmp calls within libc cannot be intercepted while their matching
longjmp calls can be.  This causes problems if our setjmp/longjmp
interceptors don't use the exact same format as libc for populating and
reading the jmp_buf.

We add a magic field to our jmp_buf and populate it in setjmp.  This
allows our longjmp interceptor to notice when a libc jmp_buf is passed
to it.

See discussion on https://reviews.llvm.org/D109699 and
https://reviews.llvm.org/D69045.

Fixes https://github.com/google/sanitizers/issues/1244.

Reviewed By: eugenis

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

This change adds the system libc++ header location to the driver. As well we define
the `__LIBC_NO_CPP_MATH_OVERLOADS__` macro when using those headers, in order to suppress
conflicting C++ overloads in the system libc headers that were used by XL C++.

Reviewed By: ZarkoCA

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

This was presumably copied from the RV32 implementation and not updated
like the rest.

\x{XXXX} \u{XXXX} and \o{OOOO} are accepted in all languages mode
in characters and string literals.

This is a feature proposed for both C++ (P2290R1) and C (N2785). The
papers have been seen by both committees but are not yet adopted into
either standard. However, they do have support from both committees.

This looks like it was copied from the RV32 version and not properly
updated. This has no functional effect but is not good style.

These got missed in D91717.

Enabled mul folding optimization that was previously disabled
by being incorrect.
To preserve correctness, mul's operand that is not compared
with zero in select's condition is now frozen.

Related bug: https://bugs.llvm.org/show_bug.cgi?id=51286

Correctness:
https://alive2.llvm.org/ce/z/bHef7J
https://alive2.llvm.org/ce/z/QcR7sf
https://alive2.llvm.org/ce/z/vvBLzt
https://alive2.llvm.org/ce/z/jGDXgq
https://alive2.llvm.org/ce/z/3Pe8Z4
https://alive2.llvm.org/ce/z/LGga8M
https://alive2.llvm.org/ce/z/CTG5fs

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

Based off the worse case numbers generated by D103695, the AVX2/512 bit reversing/counting costs were higher than necessary (based off instruction counts instead of actual throughput).

This codepath hadn't been exercised in a build with asserts before.

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

This was requested in D38253, but missed back then.

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

Summary: Making the late transformations opt-in results in less surprising behavior when composing multiple calls to the codegen strategy.

Reviewers:

Subscribers:

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

AliasInfo can now use union-find for a much more efficient implementation.
This brings no functional changes but large performance gains on more complex examples.

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

Under some situations under Thumb1, we could be stuck in an infinite
loop recombining the same instruction. This puts a limit on that, not
combining SUBC with SUBE repeatedly.

Add a set of test cases where redundant stores may be removable,
depending on whether a local allocation gets captured before performing
a load.

This extends the reduction logic in the vectorizer to handle intrinsic
versions of min and max, both the floating point variants already
created by instcombine under fastmath and the integer variants from
D98152.

As a bonus this allows us to match a chain of min or max operations into
a single reduction, similar to how add/mul/etc work.

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

When searching for hidden identity shuffles (added at rG41146bfe), only peek through bitcasts to the source operand if it is a vector type as well.

Identified in D109359.

Adds support for a feature macro `__opencl_c_images` in C++ for
OpenCL 2021 enabling a respective optional core feature from
OpenCL 3.0.

This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.

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

Identified in D109359.

Reviewed By: tra

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

E.g.:

```
%2 = memref.alloc() {alignment = 128 : i64} : memref<256x256xf32>
%3 = memref.alloc() {alignment = 128 : i64} : memref<256x256xf32>

// ... (%3 is not written to)

linalg.copy(%3, %2) : memref<256x256xf32>, memref<256x256xf32>
vector.transfer_write %11, %2[%c0, %c0] {in_bounds = [true, true]} : vector<256x256xf32>, memref<256x256xf32>
```

Avoid copies of %3 if %3 came directly from an InitTensorOp.

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

This is a first step towards addressing the last remaining limitation of
the VPlan version of sinkScalarOperands: the legacy version can
partially sink operands. For example, if a GEP has uniform users outside
the sink target block, then the legacy version will sink all scalar
GEPs, other than the one for lane 0.

This patch works towards addressing this case in the VPlan version by
detecting such cases and duplicating the sink candidate. All users
outside of the sink target will be updated to use the uniform clone.

Note that this highlights an issue with VPValue naming. If we duplicate
a replicate recipe, they will share the same underlying IR value and
both VPValues will have the same name ir<%gep>.

Reviewed By: Ayal

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

[X86][InlineAsm] Use mem size information (*word ptr) for "global variable + registers" memory expression in inline asm.

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

Create a new document that explain both stages of the process in a single
place, merge and deduplicate the content from the two previous documents. Also
extend the documentation to account for the recent changes in pass structure
due to standard dialect splitting and translation being more flexible.

Reviewed By: aartbik

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

Update the doc due to recent path changes an point to a helper script.

G_PTR_ADD (G_PTR_ADD X, C), Y) -> (G_PTR_ADD (G_PTR_ADD(X, Y), C)

Improves CTMark -Os on AArch64:

Program            before after  diff
           sqlite3 286932 287024  0.0%
                kc 432512 432508 -0.0%
             SPASS 412788 412764 -0.0%
    pairlocalalign 249460 249416 -0.0%
            bullet 475740 475512 -0.0%
    7zip-benchmark 568864 568356 -0.1%
  consumer-typeset 419088 418648 -0.1%
        tramp3d-v4 367628 367224 -0.1%
          clamscan 383184 382732 -0.1%
            lencod 430028 429284 -0.2%
Geomean difference               -0.1%

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

Added '-print-pipeline-passes' printing of parameters for those passes
declared with *_WITH_PARAMS macro in PassRegistry.def.

Note that it only prints the parameters declared inside *_WITH_PARAMS as
in a few cases there appear to be additional parameters not parsable.

The following passes are now covered (i.e. all of those with *_WITH_PARAMS in
PassRegistry.def).

LoopExtractorPass - loop-extract
HWAddressSanitizerPass - hwsan
EarlyCSEPass - early-cse
EntryExitInstrumenterPass - ee-instrument
LowerMatrixIntrinsicsPass - lower-matrix-intrinsics
LoopUnrollPass - loop-unroll
AddressSanitizerPass - asan
MemorySanitizerPass - msan
SimplifyCFGPass - simplifycfg
LoopVectorizePass - loop-vectorize
MergedLoadStoreMotionPass - mldst-motion
GVN - gvn
StackLifetimePrinterPass - print<stack-lifetime>
SimpleLoopUnswitchPass - simple-loop-unswitch

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

This check should ensure we don't reproduce the problem fixed by
02df443d

More accurately, it checks every llvm::Any::TypeId symbol in libLLVM-x.so and
make sure they have weak linkage and are not local to the library, which would
lead to duplicate definition if another weak version of the symbol is defined in
another linked library.

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

Summary: This patch implements parsing sections for obj2yaml on AIX.

Reviewed By: jhenderson

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

Invalid frame addresses exist in call stack samples due to bad unwinding. This could happen to frame-pointer-based unwinding and the callee functions that do not have the frame pointer chain set up. It isn't common when the program is built with the frame pointer omission disabled, but can still happen with third-party static libs built with frame pointer omitted.

Reviewed By: wenlei

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