Revert "[CMake] Don't set absolute paths as install runpaths on ELF platforms in llvm_setup_rpath()"

This reverts commit 8f833f88.

This would be more convenient, if ADDITIONAL_COMPILE_FLAGS(target=...)
could be set with a regular expression, just like within e.g. XFAIL
lines.

(cherry picked from commit d6622df115c0de92bf8fc10f8787345ff96b26cc)

**Currently we don't make use of the JIT for the wasm use cases so the
approach using the execution engine won't work in these cases.**

Rather if we use dlopen. We should be able to do the following
(demonstrating through a toy project)

1) Make use of LoadDynamicLibrary through the given implementation

```
extern "C" EMSCRIPTEN_KEEPALIVE int load_library(const char *name) {
  auto Err = Interp->LoadDynamicLibrary(name);
  if (Err) {
    llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "load_library error: ");
    return -1;
  }
  return 0;
}
```
2) Add a button to call load_library once the library has been added in
our MEMFS (currently we have symengine built as a SIDE MODULE and we are
loading it)

(cherry picked from commit 8f56394487a4d454be0637667267ad37bd636d0f)

Instead of always iterating over all GlobalVariable:s in the Module to
find the case where both Caller and Callee is using the same GV heavily,
first scan Callee (only if less than 200 instructions) for all GVs used
more than 10 times, and then do the counting for the Caller for just
those relevant GVs.

The limit of 200 instructions makes sense as this aims to inline a
relatively small function using a GV +10 times.

This resolves the compile time problem with zig where it is on main
(compared to removing the heuristic) a 380% increase, but with this
change <0.5% increase (total user compile time with opt).

Fixes #134714.

(cherry picked from commit 98b895da30c03b7061b8740d91c0e7998e69d091)

`clang-repl --cuda` was previously crashing with a segmentation fault,
instead of reporting a clean error
```
(base) anutosh491@Anutoshs-MacBook-Air bin % ./clang-repl --cuda
#0 0x0000000111da4fbc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x150fbc)
#1 0x0000000111da31dc llvm::sys::RunSignalHandlers() (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x14f1dc)
#2 0x0000000111da5628 SignalHandler(int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x151628)
#3 0x000000019b242de4 (/usr/lib/system/libsystem_platform.dylib+0x180482de4)
#4 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
#5 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
#6 0x0000000107f6bac8 clang::Interpreter::createWithCUDA(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x2173ac8)
#7 0x000000010206f8a8 main (/opt/local/libexec/llvm-20/bin/clang-repl+0x1000038a8)
#8 0x000000019ae8c274
Segmentation fault: 11
```

The underlying issue was that the `DeviceCompilerInstance` (used for
device-side CUDA compilation) was never initialized with a `Sema`, which
is required before constructing the `IncrementalCUDADeviceParser`.

https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/DeviceOffload.cpp#L32

https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/IncrementalParser.cpp#L31

Unlike the host-side `CompilerInstance` which runs `ExecuteAction`
inside the Interpreter constructor (thereby setting up Sema), the
device-side CI was passed into the parser uninitialized, leading to an
assertion or crash when accessing its internals.

To fix this, I refactored the `Interpreter::create` method to include an
optional `DeviceCI` parameter. If provided, we know we need to take care
of this instance too. Only then do we construct the
`IncrementalCUDADeviceParser`.

(cherry picked from commit 21fb19f3b5d572f608e959af895d781b9b24fbbd)

As per the LangRef and IEEE 754-2008 standard, the sign bit of NaN is
preserved if there is no floating-point operation being performed.
See also
https://github.com/llvm/llvm-project/commit/862e35e25a68502433da0a8d0819448ff5745339
for reference.

Alive2: https://alive2.llvm.org/ce/z/QYtEGj
Closes https://github.com/llvm/llvm-project/issues/136646

(cherry picked from commit 3e1e4062e1e95031c32c0ed9786647ef1a4141aa)

This patch disables the fold for logical is_finite test (i.e., `and
(fcmp ord x, 0), (fcmp u* x, inf) -> fcmp o* x, inf`).
It is still possible to allow this fold for several logical cases (e.g.,
`stripSignOnlyFPOps(RHS0)` does not strip any operations). Since this
patch has no real-world impact, I decided to disable this fold for all
logical cases.

Alive2: https://alive2.llvm.org/ce/z/aH4LC7
Closes https://github.com/llvm/llvm-project/issues/136650.

(cherry picked from commit 8abc917fe04140b6c6088a67e0398f637efde808)

When converting a malloc stored to a global into a global, we will
introduce an i1 flag to track whether the global has been initialized.

In case of atomic loads/stores, this will result in verifier failures,
because atomic ops on i1 are illegal. Even if we changed this to i8, I
don't think it is a good idea to change atomic types in that way.

Instead, bail out of the transform is we encounter any atomic
loads/stores of the global.

Fixes https://github.com/llvm/llvm-project/issues/137152.

(cherry picked from commit 57530c23a53b5e003d389437637f61c5b9814e22)

Hey,

This solves an issue where running lldb-server-20 with a non-absolute
path (for example, when it's installed into `/usr/bin` and the user runs
it as `lldb-server-20 ...` and not `/usr/bin/lldb-server-20 ...`) fails
with `error: spawn_process failed: execve failed: No such file or
directory`. The underlying issue is that when run that way, it attempts
to execute a binary named `lldb-server-20` from its current directory.
This is also a mild security hazard because lldb-server is often being
run as root in the directory /tmp, meaning that an unprivileged user can
create the file /tmp/lldb-server-20 and lldb-server will execute it as
root. (although, well, it's a debugging server we're talking about, so
that may not be a real concern)

I haven't previously contributed to this project; if you want me to
change anything in the code please don't hesitate to let me know.

(cherry picked from commit 945c494e2c3c078e26ff521ef3e9455e0ff764ac)

Fix #136541

(cherry picked from commit 037657de7e5ccd4a37054829874a209b82fb8be7)

This fixes a crash reported at
https://github.com/llvm/llvm-project/pull/114250#issuecomment-2813686061

If the vector type isn't legal at all, e.g. bfloat with +zvfbfmin,
then the legalized type will be scalarized. So use getScalarType()
instead of getVectorElement() when checking for f16/bf16.

(cherry picked from commit 053451cb3502144564b4d0b30a9046045d1820d4)

According to
https://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins,
result of builtin_*_overflow functions will be initialized even in case
of overflow. Align analyzer logic to docs and always initialize 3rd
argument of such builtins.

Closes #136292

(cherry picked from commit 060f9556a2f6ef4669f1c2cd8c4a4d76748a440f)

Near the ColumnLimit a break could be inserted before a right parens
with BlockIndent without a break after the matching left parens. Avoid
these hanging right parens by disallowing breaks before right parens
unless there was a break after the left parens.

Fixes #103306

(cherry picked from commit b8734797a3f605c4aaa37fcb5007baa273565460)

Original in https://github.com/llvm/llvm-project/pull/134626 was
written as if it was "this or this" but it's "this and this".

So the test ran on AArch64 Linux, because Linux is not Windows.

Split out the Windows check to fix that.

When you call the `SBTarget::ReadInstructions` with flavor from lldb
crashes. This is because the wrong order of the `DisassemblyBytes`
constructor this fixes that

---------

Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>

Instead of failing to select during isel, drop the intrinsic in
lowering.

Similar as the X86's PR. Seeing: https://reviews.llvm.org/D151050.

Fixes #134624

(cherry picked from commit dfb5b6e27ca3f8b79ebd3346d11b3088c1600b81)

Add check to make sure Dist > 0 or Dist < 0 for appropriate cmp cases to
hexagon hardware loops pass. The change modifies the
HexagonHardwareLoops pass to add runtime checks to make sure that
end_value > initial_value for less than comparisons and end_value <
initial_value for greater than comparisons.

Fix for https://github.com/llvm/llvm-project/issues/133241



@androm3da @iajbar PTAL

---------

Co-authored-by: aankit-quic <aankit@quicinc.com>
(cherry picked from commit da8ce56c53fe6e34809ba0b310fa90257e230a89)

The llvm.metadata section is not emitted and has special semantics. We
should not merge globals in it, similarly to how we already skip merging
of `llvm.xyz` globals.

Fixes https://github.com/llvm/llvm-project/issues/131394.

(cherry picked from commit 9356091a98c24718572f99b51553838ed664b67a)

This reverts commit e48916f6.

Fixes #118879

(cherry picked from commit 32c39092eab3a401d9d028c21f4707102fd70e32)

Fixes #134681

(cherry picked from commit 4ab86edb560a2e1152e22700b0cb386759286c37)

In ecc7e6ce4, we tried to inspect the `LambdaScopeInfo` on stack to
recover the instantiating lambda captures. However, there was a mismatch
in how we compared the pattern declarations of lambdas: the constraint
instantiation used a tailored `getPatternFunctionDecl()` which is
localized in SemaLambda that finds the very primal template declaration
of a lambda, while `FunctionDecl::getTemplateInstantiationPattern` finds
the latest template pattern of a lambda. This difference causes issues
when lambdas are nested, as we always want the primary template
declaration.

This corrects that by moving `Sema::addInstantiatedCapturesToScope` from
SemaConcept to SemaLambda, allowing it to use the localized version of
`getPatternFunctionDecl`.

It is also worth exploring to coalesce the implementation of
`getPatternFunctionDecl` with
`FunctionDecl::getTemplateInstantiationPattern`. But I’m leaving that
for the future, as I’d like to backport this fix (ecc7e6ce4 made the
issue more visible in clang 20, sorry!), and changing Sema’s ABI would
not be suitable in that regards. Hence, no release note.

Fixes https://github.com/llvm/llvm-project/issues/133719

(cherry picked from commit dcc2182bce3d2ef0e0a991664c51b4b3bfcf7197)

On Windows, GetProcAddress() is the API used to dynamically load
function pointers (similar to dlsym on Linux). This API returns a
function pointer (a typedef named FARPROC), which means that casting
from the call to the eventual correct type is technically a function
type mismatch on the cast. However, because this is idiomatic code on
Windows, we should accept it unless -Wcast-function-type-strict is
passed.

This was brought up in post-commit review feedback on
https://github.com/llvm/llvm-project/pull/86131

Back-porting properly freezing of the start value during epilogue
vectorization (2bdc1a1337) is non-trivial. For the 20.x release, just
disable epilogue vectorization for FindLastIV reductions where the start
value may be poison or undef.

Fixes #126836.

Tests for #126836.

Optimization of alloca instructions may lead to invalid alias tags.
Incorrect alias tags can result in incorrect optimization outcomes for
Fortran source code compiled by Flang with flags: `-O3 -mmlir
-local-alloc-tbaa -flto`.

This commit removes alias tags when memcpy optimization replaces two
arrays with one array, thus ensuring correct compilation of Fortran
source code using flags: `-O3 -mmlir -local-alloc-tbaa -flto`.

This commit is also a proposal to fix the reported issue:
https://github.com/llvm/llvm-project/issues/133984



---------

Co-authored-by: Shilei Tian <i@tianshilei.me>
(cherry picked from commit 716b02d8c575afde7af1af13df145019659abca2)

When I introduced the various `_LIBCPP_INTRODUCED_IN_LLVM_XY_ATTRIBUTE`
macros in 182f5e9b, I tried to correlate them to the right OS
versions, but it seems that I made a few mistakes. This wasn't caught in
the CI because we don't test back-deployment that far.

rdar://148405946
(cherry picked from commit a97f73405f8e074263a0ed2dd2b8c87c014f46d9)

There were some remaining headers that were not guarded with
_LIBCPP_HAS_LOCALIZATION, leading to errors when trying to use modules
on platforms that don't support localization (since all the headers get
pulled in when building the 'std' module). This patch brings these
headers in line with what we do for every other header that depends on
localization.

This patch also requires including <picolibc.h> from
<__configuration/platform.h> in order to define _NEWLIB_VERSION. In the
long term, we should use a better approach for doing that, such as
defining a macro in the __config_site header.

(cherry picked from commit 4090910a695efcba4b484e9f8ad2b564e9a4e7ed)

Using argv[0] for this was incorrect. I'm ignoring LaunchInfo::SetArg0,
as that's what darwin and windows launchers do (they use the first
element of the args vector instead).

I picked up the funny unit test re-exec method from the llvm unit tests.

(cherry picked from commit 39e7efe1e4304544289d8d1b45f4d04d11b4a791)

(cherry picked from commit 46968310cb837e4b32859edef2107080b828b117)

According to SDM, they require both VAES/VPCLMULQDQ and AVX10.1 CPUID
bits.

Fixes: #135394
(cherry picked from commit ebba554a3211b0b98d3ae33ba70f9d6ceaab6ad4)

AVX10.2 YMM rounding instructions are removed from latest AVX10 technical paper. Remove all intrinsics from compiler.

AVX10.2 saturate-convert intrinsics are modified to use "s_" in the name. It is a consensus made with GCC folks to avoid future ambiguity.

SCEV converts "-2 *nsw (i32 V)" into "2148473647 *nsw (i32 V)". But we
cannot preserve the nsw flag when the constant multiplier is negative.
This patch changes lshr to ashr so that we can preserve both nsw and nuw
flags.

Alive2 proof: https://alive2.llvm.org/ce/z/LZVSEa
Closes https://github.com/llvm/llvm-project/issues/135531.

(cherry picked from commit bb9580a02b393683ff0b6c360df684f33c715a1f)

Some new registers are reused when replacing some old ones in
certain use case of ModuloScheduleExpander. It is necessary to
avoid repeated interval calculations for these registers.

(cherry picked from commit 7e65944292278cc245e36cc6ca971654d584012d)

The interval of newly generated reg in ModuloScheduleExpander is empty.
This will cause crash at some corner case. This patch recalculate the
live intervals of these regs.

(cherry picked from commit b09b9ac1081d19c8021df8e55e96cd1325f0eed0)

(cherry picked from commit 616f277640129ff37d4005737a62acbd60d06ca1)