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

Language options are not available when a target is being created,
thus, a new method is introduced. Also, some refactoring is done,
such as removing OpenCL feature macros setting from TargetInfo.

Reviewed By: Anastasia

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

This was picking a concrete size for a physical register, and
enforcing exact match on the virtual register's type size. Some
targets add multiple types to a register class, and some are smaller
than the full bit width. For example x86 adds f32 to 128-bit xmm
registers, and AMDGPU adds i16/f16 to 32-bit registers.

It might be better to represent these cases as a copy of the full
register and an extraction of the subpart, but a lot of code assumes
you can directly copy. This will help fix the current usage of the DAG
calling convention infrastructure which is incompatible with how
GlobalISel is now using it.

The API is somewhat cumbersome here, but I just mirrored the existing
functions, except now with LLTs (and allow returning null on failure,
unlike the MVT version). I think the concept of selecting register
classes based on type is flawed to begin with, but I'm trying to keep
this compatible with the existing handling.

This patch simplifies the calculation of certain costs in
getInstructionCost when isScalarAfterVectorization() returns a true value.
There are a few places where we multiply a cost by a number N, i.e.

  unsigned N = isScalarAfterVectorization(I, VF) ? VF.getKnownMinValue() : 1;
  return N * TTI.getArithmeticInstrCost(...

After some investigation it seems that there are only these cases that occur
in practice:

1. VF is a scalar, in which case N = 1.
2. VF is a vector. We can only get here if: a) the instruction is a
GEP/bitcast/PHI with scalar uses, or b) this is an update to an induction
variable that remains scalar.

I have changed the code so that N is assumed to always be 1. For GEPs
the cost is always 0, since this is calculated later on as part of the
load/store cost. PHI nodes are costed separately and were never previously
multiplied by VF. For all other cases I have added an assert that none of
the users needs scalarising, which didn't fire in any unit tests.

Only one test required fixing and I believe the original cost for the scalar
add instruction to have been wrong, since only one copy remains after
vectorisation.

I have also added a new test for the case when a pointer PHI feeds directly
into a store that will be scalarised as we were previously never testing it.

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

Need to respect mapping/privatization of declare target variables in the
target regions if explicitly specified by the user.

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

Tensor inputs, if not used in the body of TiledLoopOp, can be removed.
memref::CastOp can be folded into TiledLoopOp as well.

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