This uses to be how predicates were handled prior to HwMode being
added. When the Predicates were converted to a std::vector it
significantly increased the cost of a compare in GenerateVariants.
Since ListInit's are uniquified by tablegen, we can use a simple
pointer comparison to check for identical lists.

In order to store the HwMode, we now add a separate string to
PatternToMatch. This will be appended separately to the predicate
string in getPredicateCheck. A new getPredicateRecords is added
to allow GlobalISel and getPredicateCheck to both get the sorted
list of Records. GlobalISel was ignoring any HwMode predicates
before and still is.

There is one slight change here, ListInits with different predicate
orders aren't sorted so the filtering in GenerateVariants might
fail to detect two isomorphic patterns with different predicate
orders. This doesn't seem to be happening in tree today.

My hope is this will allow us to remove all the BitVector tracking
in GenerateVariants that was making up for predicates beeing
expensive to compare. There's a decent amount of heap allocations
there on large targets like X86, AMDGPU, and RISCV.

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

The buildbots now have bash available in the path from the start.

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

The Neon vadd intrinsics were added to the ARMSIMD intrinsic map,
however due to being defined under an AArch64 guard in arm_neon.td,
were not previously useable on ARM. This change rectifies that.

It is important to note that poly128 is not valid on ARM, thus it was
extracted out of the original arm_neon.td definition and separated
for the sake of AArch64.

Reviewed By: DavidSpickett

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

Canonicalizations for subtensor operations defaulted to use the
rank-reduced version of the operation, but the cast inserted to get
back the original type would be illegal if the rank was actually
reduced. Instead make the canonicalization not reduce the rank of the
operation.

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

Add a flag to change dsymutil's behavior and force a static variable to
keep its enclosing function. The test shows a situation where that could
be useful. I'm not convinced this behavior makes sense as a default,
which is why it's behind a flag.

rdar://74918374

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

Note, only src0 and src1 will be commuted if the isCommutable flag
is set. This patch does not change that, it just makes it possible
to commute src0 and src1 of some U/I/B vop3 instructions.

This patch revises d35d8da7.
It contains the commute opportunities excluding float insts

Reviewed By: rampitec

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

Change-Id: I62938173d750453839f2457a3851661a29135faf

The current canonicalization did not remap operation results correctly
and attempted to erase tiledLoop, which is incorrect if not all tensor
results are folded.

Just like the in case for function and data symbols this is needed to
support relocations in debug info sections which are allowed contains
relocations against non-live symbols.

The motivating use case is an object file that contains debug info that
references `__stack_pointer` (a local symbol) but does not actually
contain any uses of `__stack_pointer`.

Fixes: https://github.com/emscripten-core/emscripten/issues/14025

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

Before the script detected non-ASCII characters but let them pass. This
fixes the issue. I had a way to solve the issue, during review @Quuxplusone
suggested a better alternative. The patch has been changed to use this alternative.

Intended failed builds:
- Not updated generated files https://buildkite.com/llvm-project/libcxx-ci/builds/2822
- Not updated generated files and non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2835
- Non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2836

Reviewed By: #libc, Quuxplusone, curdeius

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

Reduces numbers of files built for clang-format from 575 to 449.

Requires two small changes:

1. Don't use llvm::ExceptionHandling in LangOptions. This isn't
   even quite the right type since we don't use all of its values.
   Tweaks the changes made in:
   - https://reviews.llvm.org/D93215
   - https://reviews.llvm.org/D93216

2. Move section name validation code added (long ago) in commit 30ba6743 out
   of libBasic into Sema and base the check on the triple. This is a bit less
   OOP-y, but completely in line with what we do in many other places in Sema.

No behavior change.

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

Note that we don't want to turn a partially-direct call
into an indirect one, that will break ICP amongst other things.

This is the pattern ICP produces.
We shouldn't fold this back into an indirect call.

When searching for stores and creating corresponding notes, the
analyzer is more specific about the target region of the store
as opposed to the stored value.  While this description was tweaked
for constant and undefined values, it lacked in the most general
case of symbolic values.

This patch tries to find a memory region, where this value is stored,
to use it as a better alias for the value.

rdar://76645710

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

Since we can report memory leaks on one variable, while the originally
allocated object was stored into another one, we should explain
how did it get there.

rdar://76645710

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

When reporting leaks, we try to attach the leaking object to some
variable, so it's easier to understand.  Before the patch, we always
tried to use the first variable that stored the object in question.
This can get very confusing for the user, if that variable doesn't
contain that object at the moment of the actual leak.  In many cases,
the warning is dismissed as false positive and it is effectively a
false positive when we fail to properly explain the warning to the
user.

This patch addresses the bigest issue in cases like this.  Now we
check if the variable still contains the leaking symbolic object.
If not, we look for the last variable to actually hold it and use
that variable instead.

rdar://76645710

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

Allocation site is the key location for the leak checker.  It is a
uniqueing location for the report and a source of information for
the warning's message.

Before this patch, we calculated and used it twice in bug report and
in bug report visitor.  Such duplication is not only harmful
performance-wise (not much, but still), but also design-wise.  Because
changing something about the end piece of the report should've been
repeated for description as well.

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

This patch changes the AArch32 crypto instructions (sha2 and aes) to
require the specific sha2 or aes features. These features have
already been implemented and can be controlled through the command
line, but do not have the expected result (i.e. `+noaes` will not
disable aes instructions). The crypto feature retains its existing
meaning of both sha2 and aes.

Several small changes are included due to the knock-on effect this has:

- The AArch32 driver has been modified to ensure sha2/aes is correctly
  set based on arch/cpu/fpu selection and feature ordering.
- Crypto extensions are permitted for AArch32 v8-R profile, but not
  enabled by default.
- ACLE feature macros have been updated with the fine grained crypto
  algorithms. These are also used by AArch64.
- Various tests updated due to the change in feature lists and macros.

Reviewed By: lenary

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

This reverts commit dca53610.

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

since the `async` keyword is reserved in python, the dialect is called async_dialect.

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

Seems to break indirect call promotion, LTO/Resolution/X86/load-sample-prof-icp.ll fails.

This reverts commit e57cf128.

Before this change LLVM cannot simplify printf in following cases:

printf("%s", "") --> noop
printf("%s", str"\n") --> puts(str)

From the other hand GCC can perform such transformations for many years:
https://godbolt.org/z/7nnqbedfe

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

Commit 2a133224 extracted this code to a new function checkSectionName() and
added a call to it, but didn't remove the original code. The original code
is dead since the checkSectionName() early return would fire when it would
trigger. (If it weren't dead, it'd make clang crash since
err_attribute_section_invalid_for_target now takes two args instead of just the
one that's passed.)

No behavior change.

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

Add a call to skipFunction().

This patch fixes a crash encountered when vectorising the following loop:

 void foo(float *dst, float *src, long long n) {
   for (long long i = 0; i < n; i++)
     dst[i] = -src[i];
 }

using scalable vectors. I've added a test to

 Transforms/LoopVectorize/AArch64/sve-basic-vec.ll

as well as cleaned up the other tests in the same file.

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

In particular, `span<int>::iterator` may be a raw pointer type
and thus have no nested typedef `iterator::value_type`. However,
we already know that the value_type we expect for `span<int>` is just `int`.
Fix up all other iterator_concept_conformance tests in the same way.

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

Class properties are always implicit short-hands for the getter/setter
class methods.

We need to explicitly visit the interface decl `UIColor` in `UIColor.blueColor`,
otherwise we instead show the method decl even while hovering over
`UIColor` in the expression.

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

!find searches a source string for a target string and returns the position.

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

If the first tree element is vectorize and the second is gather, it
still might be profitable to vectorize it if the gather node contains
less scalars to vectorize than the original tree node. It might be
profitable to use shuffles.

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

This is useful for running in batch mode.
Getting the SymbolID from via getSymbolInfo may give SymbolID
of a symbol different from that located by LocateSymbolAt (they
have different semantics of choosing the symbol.)

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