…nces"

This reverts commit 5a5ac65.

(cherry picked from commit ae2638d)
(cherry picked from commit 05848b6)

Julia uses addressspaces for GC and we want these to be sanitized as well.

(cherry picked from commit 3f53397)
(cherry picked from commit 58df73b)

Otherwise clang installs all of its tools into `bin/` while
LLVM installs its tools into (LLVM_TOOLS_INSTALL_DIR).
I could swear this used to work (and in fact the julia build system
assumes it), but I can't pin down a specific commit that would
have broken this, and julia has been relying on pre-compiled binaries
for a while now (that don't use this setting), so it may have been
broken for quite a while.

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

(cherry picked from commit 6104e14)
(cherry picked from commit f252e17)
(cherry picked from commit 9039ce8)

IIUC we can't emit `memcmp` between pointers in addressspaces,
doing so will trigger an assertion since the signature of the memcmp
will not match it's arguments (https://bugs.llvm.org/show_bug.cgi?id=48661).

This PR disables the attempt to merge icmps,
when the pointer is in an addressspace.

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

(cherry picked from commit 458b259)
(cherry picked from commit aaf2d27)

(cherry picked from commit 5393efb)

Co-authored-by: Valentin Churavy <v.churavy@gmail.com>
Co-authored-by: Julian P Samaroo <jpsamaroo@jpsamaroo.me>
(cherry picked from commit a0defe0)

Follow-up on https://reviews.llvm.org/D118970 FP_XSTATE_MAGIC1 is only available on glibc 2.27 and upwards

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

We need to force the emission of the EH Frame section (currently done via SupportsCompactUnwindWithoutEHFrame in the MCObjectFileInfo for the target), since libunwind doesn't yet support dynamically registering compact unwind information at run-time.

(cherry picked from commit 60e0418)
(cherry picked from commit 6275013)

PrintIRInstrumentation::shouldPrintAfterPass accepts a pass ID instead of a pass name

Reviewed By: aeubanks

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

(cherry picked from commit d4de7c2)

`SimplifySelectOps` is a late optimization in LLVM that attempts to
translate `select(C, load(A), load(B))` into `load(select(C, A, B))`.
However, in order for it to do this optimization, it needs to check that
`C` does not depend on the result of `load(A)` or `load(B)`.
Unfortunately (unlikely Julia and LLVM at the IR level), LLVM does not
have a topological order of statements computed at this stage of the
compiler, so LLVM needs to iterate through all statements in the
function in order to perform this legality check. For large functions,
this is extremely expensive, accounting for the majority of all
compilation time for such functions. On the other hand, the optimization
itself is minor, allowing at most the elision of one additional load
(and doesn't fire particularly often, because the middle end can perform
similar optimizations). Until there is a proper solution in LLVM, simply
disable this optimizations, making LLVM several orders of magnitude
faster on real world benchmarks.

X-ref: llvm#60132

As shown in issue llvm#60649, the new shuffles were
being inserted before a phi, and that is invalid.

It seems like most test coverage for this fold
(foldSelectShuffle) lives in the AArch64 dir,
but this doesn't repro there for a base target.