Previously, dontcall attribute message on LTO prints the mangled function name.

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

Relanded with proper IR -> Demangle dependency.

Reviewed By: aeubanks

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

This reverts commit cb05c2ff.

Breaks https://lab.llvm.org/buildbot/#/builders/121/builds/27524/steps/4/logs/stdio

This was missing important environment context, like denormal-fp-math
and target-features. Curiously this seems to be losing nounwind. Note
this only fixes the actual invoke kernel. The invoke function is
already setting the default attribute set for internal
functions. However that is still buggy since it's not applying any use
function attributes (it's also missing uniform-work-group-size).

There seem to be too many different functions for setting attributes
with inconsistent behavior. The Function overload of
addDefaultFunctionAttributes seems to miss the target-cpu and
target-features. The AttrBuilder one seems to miss optnone (but that
seems to be disallowed on blocks anyway). Neither one calls
setTargetAttributes, when it probably should. uniform-work-group-size
is also set through AMDGPU code when it should be emitting generically
as a language property.

I also noticed update_cc_test_checks for attributes seem to not
connect the captured attribute variables to the attributes at the end
(although I think the numbers happen to work out correctly).

Baseline tests showing that enqueued blocks are not getting the
correct attributes applied.

Yet another example how convergent not being the default is dangerous
and backwards.

The AMDGPU value for this is not really a function. Currently we're
emitting IR that isn't true to what will eventually be emitted.

Previously, dontcall attribute message on LTO prints the mangled function name.

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

Reviewed By: aeubanks

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

This will help with finding potential pathological CGSCC cases.

Reviewed By: asbirlea

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

This brings the operand order in line with the NUW handling, which was
missed out in 72121a20.

At the moment this is NFC as we only additions, but it
should fix miscompiles with 024115ab recommitted.

D108961 will add more instructions to this.

This reverts commit 7f0003c1.

Reason: This broke the ASan buildbot, see the comments in
https://reviews.llvm.org/D138986 for more information.

Reviewed By: Mordante, #libc

Spies: libcxx-commits

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

Reviewed By: lntue

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

Reviewed By: lntue

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

The conversion of dbg.declare into dbg.values doesn't take into account
the DIExpression attached to the intrinsic. In particular, when
converting:

```
store %val, ptr %alloca
dbg.declare(ptr %alloca, !SomeVar, !DIExpression())
```

Mem2Reg will try to figure out if `%val` has the size of `!SomeVar`. If
it does, then a non-undef dbg.value is inserted:

```
dbg.value(%val, !SomeVar, !DIExpression())
```

This makes sense: the alloca is _the_ address of the variable. So a
store to the alloca is a store to the variable. However, if the
expression in the original intrinsic is a `DW_OP_deref`, this logic is
not applicable:

```
store ptr %val, ptr %alloca
dbg.declare(ptr %alloca, !SomeVar, !DIExpression(DW_OP_deref))
```

Here, the alloca is *not* the address of the variable. A store to the
alloca is *not* a store to the variable. As such, querying whether
`%val` has the same size as `!SomeVar` is meaningless.

This patch addresses the issue by:...

This replaces AEK_CRYPTO in the AArch64TargetParser definitions,
replacing the composite Crypto features with the constituent parts.
AEK_CRYPTO is replaced with either AEK_AES | AEK_SHA2 or AEK_AES |
AEK_SHA2 | AEK_SHA3 | AEK_SHA4 depending on if the cpu is Arm-v8.4+.
This helps get the features correct in some more places like
target(cpu=..) attributes.

Otherwise this is hopefully an NFC for -mcpu options but seems like a
cleaner design.

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

Our implementation of std::format assumed that string_view's iterators
were raw pointers in various places. If we want to introduce a checked
iterator in debug mode, that won't be true anymore. This patch removes
that assumption.

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

The revision adds support to import access group metadata from LLVM IR.
It closely follows the design of the TBAA metadata import with an
up-front conversion of the metadata nodes to operations stored in the
body of a module-level metadata operation. The revision chooses to use
only one module-level metadata operation for all kinds of metadata.
This  design ensures there is only one metadata operation that pollutes
the user namespace.

The import of loop metadata, which will use the access groups,
is left to a follow up revision.

Reviewed By: Dinistro

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

Fixes #59443  https://github.com/llvm/llvm-project/issues/59443

getNumVars will add locals and cause out of bound access.

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

PSA: https://discourse.llvm.org/t/psa-retire-tileandfuselinalgops-method/63850

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

Extend `LLVMInlinerInterface` to inline lifetime intrinsics for
`LLVM::AllocaOp` operations, and to insert new lifetime intrinsics when
an alloca is moved to the entry block that restrict its scope to where
the call was before inlining.

Depends on D142436

Reviewed By: gysit

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

Summary:
The previous patch didn't remove these tests correctly.

Minor cleanup before we can handle any_of(icmp_ne) with the same code.

I missed a second title with too short of underlining.

This addresses the issue found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/31313

Summary:
These don't need to be set.

Recommitting after fixing scalable vector crash.

Check for single smax pattern against zero when converting from a
small enough float.

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

This caused false container-overflow errors when using a custom allocator that
touches the memory on deallocation: GitHub Issue #60384

> This revision is a part of a series of patches extending
> AddressSanitizer C++ container overflow detection
> capabilities by adding annotations, similar to those existing
> in std::vector, to std::string and std::deque collections.
> These changes allow ASan to detect cases when the instrumented
> program accesses memory which is internally allocated by
> the collection but is still not in-use (accesses before or
> after the stored elements for std::deque, or between the size and
> capacity bounds for std::string).
>
> The motivation for the research and those changes was a bug,
> found by Trail of Bits, in a real code where an out-of-bounds read
> could happen as two strings were compared via a std::equals function
> that took iter1_begin, iter1_end, iter2_begin iterators
> (with a custom comparison function).
> When object iter1 was longer than iter2, read out-of-bounds on iter2
> could happen. Container sanitization would detect it.
>
> In revision D132522, support for non-aligned memory buffers (sharing
> first/last granule with other objects) was added, therefore the
> check for standard allocator is not necessary anymore.
> This patch removes the check in std::vector annotation member
> function (__annotate_contiguous_container) to support
> different allocators.
>
> If you have any questions, please email:
>  - advenam.tacet@trailofbits.com
>  - disconnect3d@trailofbits.com
>
> Reviewed By: #libc, #sanitizers, philnik, vitalybuka
>
> Spies: EricWF, philnik, #sanitizers, libcxx-commits
>
> Differential Revision: https://reviews.llvm.org/D136765

This reverts commit 49055502.

Simple fix to check for rank in the same way as other intrinsics to allow
runtime count to take over when dealing with unknown dimension arrays.

Fixes #60356

Reviewed By: Leporacanthicus

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

This reverts commit e1bbe50f.

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

FEAT_LSE128 implies FEAT_LSE but not FEAT_LSE2, so add tests showing
what happens when you have both.

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

These tests explicitly make use of POSIX absolute paths.

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

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

VPPredInstPHIRecipe just merges the incoming values and does not write
to memory.

The previous T2 ADC instruction requires three operands. This patch
supports its shortened forms.

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