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

So far, only a conversion for complex::AbsOp is done, but more will be added.

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

This reverts commit e1021dd1.

This patch also refactors the way the feasible max VF is calculated,
although this is NFC for fixed-width vectors.

After this change scalable VF hints are no longer truncated/clamped
to a shorter scalable VF, nor does it drop the 'scalable flag' from
the suggested VF to vectorize with a similar VF that is fixed.

Instead, the hint is ignored which means the vectorizer is free
to find a more suitable VF, using the CostModel to determine the
best possible VF.

Reviewed By: c-rhodes, fhahn

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

Previously printing R_386_RELATIVE relocations would trigger
`error: can't read an entry at 0x40: it goes past the end of the section (0x40)`
I found this while writing a test case for LLD (D100490).
This also includes some minor cleanup in the elf-dynamic-relcos.test
llvm-objdump test based on the newly added test.

Reviewed By: jhenderson, MaskRay

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

The original page no longer works, so use a web.archive.org link instead.

Reviewed By: atanasyan

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

While implementing support for the float128 routines on x86_64, I noticed
that __builtin_isinf() was returning true for 128-bit floating point
values that are not infinite when compiling with GCC and using the
compiler-rt implementation of the soft-float comparison functions.
After stepping through the assembly, I discovered that this was caused by
GCC assuming a sign-extended 64-bit -1 result, but our implementation
returns an enum (which then has zeroes in the upper bits) and therefore
causes the comparison with -1 to fail.

Fix this by using a CMP_RESULT typedef and add a static_assert that it
matches the GCC soft-float comparison return type when compiling with GCC
(GCC has a __libgcc_cmp_return__ mode that can be used for this purpose).

Also move the 3 copies of the same code to a shared .inc file.

Reviewed By: compnerd

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

This has been rather useful in our downstream CHERI target where we want
to run tests both with addrspace(0) and addrspace(200) pointers.
With this patch we can prefix the opt command with
`sed -e 's/addrspace(200)/addrspace(0)/g' -e 's/-A200-P200-G200//g'` to
test both cases using the same IR input.

Reviewed By: jdoerfert

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