Created using spr 1.3.5-bogner

xray instruments tail call function exits by inserting a nop sled before
the tail call. When tracing is enabled, the nop sled is replaced with a
call to `__xray_FunctionTailExit()`. This currently does not work for
conditional tail calls, as the instrumentation assumes that the tail
call will be unconditional. This causes two issues:
 - `__xray_FunctionTailExit()` is inappropately called even when the
   tail call is not taken.
 - `__xray_FunctionTailExit()`'s prologue/epilogue adjusts the stack
   pointer with add/sub instructions. This clobbers condition flags,
   which can flip the condition used for the tail call, leading to
   incorrect program behavior.

Fix this by rewriting conditional calls when lowering patchable tail
calls.

With this change, a conditional patchable tail call like:
```
  je target
```

Will be lowered to:
```
  jne .fallthrough
  .p2align 1, ..
.Lxray_sled_N:
  SLED_CODE
  jmp target
.fallthrough:
```

Calls to @llvm.xray.{custom,typed}event are lowered to an nop sled that
can be
patched with a call to an instrumentation function at runtime. Prior to
this
change, x86 codegen did not guarantee that these patched calls run with
the
appropriate stack alignment (particularly in leaf functions, where
normal stack
alignment assumptions may not hold).

This leads to crashes on x86, as the custom event hook can end up using
SSE
instructions that assume a 16-byte aligned stack.

Fix this by wrapping custom event hooks in CALLSEQ_START/CALLSEQ_END as
done for
regular function calls. One downside of this approach is that on
functions whose
stacks aren't already aligned, we may end up running stack alignment
fixup
instructions even when instrumentation is disabled. An alternative could
be to
make the custom event assembly trampolines stack-alignment-agnostic.
This was
the case in the past, but

https://github.com/llvm/llvm-project/commit/b46c89892fe25bec197fd30f09b3a312da126422
removed this due to complexity in maintaining CFI directives for these
stack
adjustments. Since we are already willing to pay the call argument setup
cost
for custom hooks when instrumentation is disabled, I am hoping that an
extra
push/pop in this hopefully uncommon unaligned stack case is tolerable.

This is for the coming NF (no flags update) support in flag copy
lowering.

This change adds the `--keep-icf-stabs` which, when specified, preserves
symbols that were folded by ICF in the binary's stabs entries.
This allows `dsymutil` to process debug information for the folded
symbols.

Similar to previous cleanup.

While changing mips* tests, change some -no-integrated-as to the
recommended -fno-integrated-as.

I found we may insert unused implciit declarations like AArch SVE
declarations by default on AArch64 due to we will insert that by
default. But it should be completely redundant and this patch tries to
remove that.

As a follow-up to b2f65e80, use the DTU to also update and preserve
the DT in the native path. This should also allow preserving SCEV in the
native path

PR: https://github.com/llvm/llvm-project/pull/93287

- Add `vector.interleave` to `spirv.VectorShuffle` conversion
- Remove the `vector.interleave` to `vector.shuffle` conversion from
`populateVectorToSPIRVPatterns` and CMake/Bazel dependencies

---------

Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com>

Before this change, the FDR BufferQueue iterator could access oob memory
due to checks of the form `!Buffers[Offset].Used && Offset != Max`. This
allows access to `Buffers[Max]`, which is past the end of the `Buffers`
array. This can lead to crashes when that memory is not mapped. Fix this
by testing `Offset != Max` first.

Previously, some xray trampolines would modify condition codes (before
saving/after restoring flags) due to stack alignment instructions, which
use add/sub.

I am not aware of issues that this causes in practice (outside of the
situation described in https://github.com/llvm/llvm-project/pull/89364,
which is only problematic due to a different bug). Nevertheless, it
seems nicer and less error-prone for xray instrumentation to be as
unobstrusive/preserve as much state as possible.

As the comment added by a0772719
suggests, these `*Triples` lists should shrink over time.

https://reviews.llvm.org/D158183 allows *-unknown-linux-gnu to detect
*-linux-gnu. If we additionally allow x86_64-unknown-linux-gnu
-m32/-mx32 to detect x86_64-linux-gnu, we can mostly remove these
*-linux-gnu elements.

Following the discussion in
https://github.com/llvm/llvm-project/pull/93233#issuecomment-2127920882,
this patch merges `clang-ci` pipeline into main `GitHub Pull Requests`
pipeline. `clang-ci` enables additional test coverage for Clang by
compiling it, and then using it to compile and test libc++, libc++abi,
and libunwind in C++03, C++26, and Clang Modules modes.

Additional work we skip and total time savings we should see:
1. Checking out the repo to generate the clang-ci pipeline (2 minutes)
2. Building Clang (3.5 minutes)
3. Uploading the artifacts once, then downloading them 3 times and
unpacking 3 times (0.5 minutes)

Note that because previously-split jobs for each mode are now under a
single Linux job, it now takes around 8 minutes more see the Linux CI
results despite total time savings.

The primary goal of this patch is to reduce the load of CI by removing
duplicated work. I consider this goal achieved. I could keep the job
parallelism we had (3 libc++ jobs depending on a main Linux job), but I
don't consider it worth the effort and opportunity cost, because
parallelism is not helping once the pool of builders is fully
subscribed.

Closes #92999.

This is an intermediate step towards the PSTL dispatching mechanism
rework. It will make it a lot easier to track the upcoming front-end
changes. After the rework, there are basically no implementation details
in the front-end, so the definition of each algorithm will become much
simpler. Otherwise, it wouldn't make sense to define all the algorithms
in the same header.

`AArch64PAuth::checkAuthenticatedRegister()` splits the basic block
containing the tail call instruction to add check instructions, assuming
at least one more instruction before the call. This assumption is
incorrect in cases where some execution paths lead to the termination
block without creating the stack frame. This patch rearranges the
creation of the checks so that the prior splitting is not required.

Similar to some other platforms, AIX uses ' ' for non-wide characters
and U202F for wide characters, so this change opts into those paths for
AIX as well.

Commit 1db51d8e switched from int64_t to `APInt` to prevent high precision integer overflow.
However, when comparing the "range" of switch cases, we should switch to unsigned integer to prevent overflow.
This patch fixes https://github.com/llvm/llvm-project/issues/93152

. 
Some test cases are added.

Signed-off-by: Peter Rong <PeterRong96@gmail.com>

Replace the use of `pipes.quote()` with `shlex.quote()` to fix
compatibility with Python 3.13. The former was always an undocumented
alias to the latter, and the `pipes` module was removed completely in
Python 3.13.

Fixes #93375

A full downstream fork can already hack up update_llc_test_checks.py to
support custom tools that output assembly.

An out-of-tree frontend which is meant to build against upstream
llvm-project cannot do this, and so providing additional arguments to
support a non-standard tool is useful.

This also makes a minor adjustment to the regular expression for
matching AMDGPU functions when fewer comments are enabled, which happens
to be the case for our out-of-tree shader compiler (which motivated this
change).

Call `DiagnoseUnexpandedParameterPack` when we parse an expression
argument to an attribute and check for implicit code in the
`CollectUnexpandedParameterPacksVisitor` so we can actually find
unexpanded packs in attributes that end up applied to lambda call
operators.

This fixes #93269.

Fix a regression introduced by #88740

Fixes #92275

This should have been removed from #89744 to address a review comment.

This was committed by mistake. We don't store that file in the source
tree anymore, we only generate it upon installation.

This is to make it more obvious for what the result type is, especially
with some less trivial cases like 0-d inputs resulting in 1-d inputs or
interaction with scalable vector types. Note that `vector.deinterleave`
uses the same format with explicit result type.

Also improve examples and clean up surrounding code.

This implements the `nusw` and `nuw` flags for `getelementptr` as
proposed at
https://discourse.llvm.org/t/rfc-add-nusw-and-nuw-flags-for-getelementptr/78672.

The three possible flags are encapsulated in the new `GEPNoWrapFlags`
class. Currently this class has a ctor from bool, interpreted as the
InBounds flag. This ctor should be removed in the future, as code gets
migrated to handle all flags.

There are a few places annotated with `TODO(gep_nowrap)`, where I've had
to touch code but opted to not infer or precisely preserve the new
flags, so as to keep this as NFC as possible and make sure any changes
of that kind get test coverage when they are made.

Currently, if the argument to `__builtin_assume` and friends contains
side-effects, we issue the following diagnostic:
```
<source>:1:34: warning: the argument to '__builtin_assume' has side 
effects that will be discarded [-Wassume]
    1 | void f(int x) { __builtin_assume(x++); }
      |                                  
```
The issue here is that this diagnostic misrepresents what is actually
happening: not only do we discard the side-effects of the expression,
but we also don’t even emit any assumption information at all because
the backend is not equipped to deal with eliminating side-effects in
cases such as this.

This has caused some confusion (see #91612) beacuse the current wording
of the warning suggests that, sensibly, only the side-effects of the
expression, and not the assumption itself, will be discarded.

This pr updates the diagnostic to state what is actually happening: that
the assumption has no effect at all because its argument contains
side-effects:
```
<source>:1:34: warning: assumption is ignored because it contains 
(potential) side-effects [-Wassume]
    1 | void f(int x) { __builtin_assume(x++); }
      |                                  
```

I’ve deliberately included ‘(potential)’ here because even expressions
that only contain potential side-effects (e.g. `true ? x : x++` or a
call to a function that is pure, but we don’t know that it is) cause the
assumption to be discarded. This, too, has caused some confusion because
it was erroneously assumed that Clang would e.g. infer that a function
call is pure and not discard the assumption as a result when that isn’t
the case.

This is intended to be temporary; we should revert back to the original
diagnostic once we have proper support for assumptions with side-effects
in the backend (in which case the side-effects will still be discarded,
but the assumption won’t)

This fixes #91612.

[LoopCacheAnalysis] Fix loop cache cost to always round the cost up to the nearest integer number (#88915)

Currently loop cache analysis uses following formula to evaluate cost of
an RefGroup for a consecutive memory access:

`RefCost=(TripCount*Stride)/CLS`

This cost evaluates to zero when `TripCount*Stride` is smaller than
cache-line-size. This results in wrong cost value for a loop and
misleads loopInterchange decisions as shown in [this
case](https://llvm.godbolt.org/z/jTz1vn4hn).

This patch fixes the problem by rounding the cost to 1 once this problem
happens.

[Clang] Issue an error when an atomic builtin is called with a pointer to a zero-size object (#91057)

When an atomic builtin is called with a pointer to an object of size
zero, an arithmetic exception gets thrown because there is a modulo
operation with the objects size in codegen.

Diagnose this in sema instead.

Fixes #90330.

Previously, we pushed a pointer to the stack and later tried to use
it as if it was a function pointer, which doesn't work.

So I don't have to count them down all the time.

Fix #85069 .