Rename CalleeSavedRegs defs to avoid being overly specific:

* CSR_AMDGPU_AGPRs_32_255 => CSR_AMDGPU_AGPRs
* CSR_AMDGPU_SGPRs_30_31 + CSR_AMDGPU_SGPRs_32_105 => CSR_AMDGPU_SGPRs
* CSR_AMDGPU_SI_Gfx_SGPRs_4_29 + CSR_AMDGPU_SI_Gfx_SGPRs_64_105 =>
  CSR_AMDGPU_SI_Gfx_SGPRs
* CSR_AMDGPU_HighRegs => CSR_AMDGPU
* CSR_AMDGPU_HighRegs_With_AGPRs => CSR_AMDGPU_GFX90AInsts
* CSR_AMDGPU_SI_Gfx_With_AGPRs => CSR_AMDGPU_SI_Gfx_GFX90AInsts

Introduce a class RegMask to mark the cases where we use the
CalleeSavedRegs class purely as an expedient way to produce a mask.
Update the names of these masks to not mention "CSR". Other targets also
seem to do this, so a reasonable alternative is to actually update
table-gen to include a new class to do this explicitly, but the current
approach seems harmless so I opted to just make it more explicit.

Reviewed By: arsenm, sebastian-ne

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

As per issue #1196, the loop induction variable, which is an argument
in the omp.wsloop operation, does not have a memory location, so when
passed to a function or subroutine, the reference to the value is not
a memory location, but the value of the induction variable. The callee
function/subroutine is then trying to dereference memory at address 1
or some other "not a good memory location".

This is fixed by creating a temporary memory location and storing the
value of the induction variable in that.

Test fixes as a consequence of the changed code generated.

Add checking for some of the omp-unstructured.f90 to check for alloca,
store and load operations, to ensure the correct flow. Add a test
for CYCLE inside a omp-do loop.

Also convert to use -emit-fir in the omp-unstructrued, and make
the symbol matching consistent in the omp-wsloop-variable test.

Reviewed By: peixin

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

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

This fillRow(..., 0) is redundant because when the size of the tableau is
consistent, the resize always creates a new row, which is zero-initialized.

Also added asserts throughout to ensure the dimensions of the tableau remain
consistent.

Reviewed By: Groverkss

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

This resolves a comment from https://reviews.llvm.org/D126708
that was previously missed.

This gives a 1.5x speedup on the Presburger unittests.

Reviewed By: Groverkss

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

Formatting a string-literal had an off-by-one issue where the NUL
terminator became part of the formatted output.

Reviewed By: #libc, ldionne

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

Fix the warning: comparison of unsigned expression in ‘>= 0’ is always
true.

Reviewed By: kiranchandramohan, shraiysh

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

"std::has_unique_object_representations<_BitInt(N)>" was always true,
even if the type has padding bits (since the trait assumes all integer
types have no padding bits). The standard has an explicit note that
this should not hold for types with padding bits.

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

Clang currently warns on definitions downgraded to declarations
with a const modifier, but not for a constexpr modifier. This patch
updates the warning logic to warn on both inputs, and adds a test to
check the additional case as well.

See also: https://bugs.chromium.org/p/chromium/issues/detail?id=1284718

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

We enable a custom handler to optimize conversions between scalars
and fixed vectors. Unfortunately, the custom handler picks up scalar
to scalar conversions as well. If the scalar types are both legal,
we wouldn't match any of the fixed vector cases and would return SDValue()
causing the LegalizeDAG to expand the bitcast through memory.

This patch fixes this by checking if it's a scalar to scalar conversion
and returns `Op` if both types are legal.

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

This patch supports the following checks:
```
[5.1] 2.21.2 THREADPRIVATE Directive
The threadprivate directive must appear in the declaration section of
a scoping unit in which the common block or variable is declared.
[5.1] 2.14.7 Declare Target Directive
The directive must appear in the declaration section of a scoping unit
in which the common block or variable is declared.
```
Reviewed By: kiranchandramohan, shraiysh, NimishMishra

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

D124631 added special processing for STATEPOINT instructions.
It appears that assertion added there is too strong. We can get two
tied operands with the same register tied to different defs. If we
hit such case, do not process it in statepoint-specific code and
delegate it to common case.

[ARM] uxtb.ll - adjust armv6 triple so the update_llc_test_checks.py script can be used to regenerate the tests

No need to specify armv6-apple-darwin in these UXTB codegen tests

As discussed on D77804, instcombine will have already performed a similar SimplifyMultipleUseDemandedBits call which will break the UXTB16 pattern that was being match in these DAG tests

I've updated the existing tests so that it match the instcombine IR (with a suitable FIXME) and added an equivalent test pattern suggested by @dmgreen

Unfortunately I don't have a reproducer for this.
Reported by @mikaelholmen!

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

We may need to peek through a bitcast when identifying an fneg idiom
via its pool constant, but we can't allow a different-sized constant
in that match.

This is noted in issue #55758 with an example that needs fast-math,
but as the test here shows, this has potential to miscompile more
generally (no fast-math required).

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

Avoid the dependency on TargetInstrInfo, which depends on the subtarget
and therefore the individual function.

Currently AMDGPU is constructing PseudoSourceValue instances in MachineFunctionInfo.
In order to facilitate copying MachineFunctionInfo, we need to stop allocating these
there. Alternatively we could allow targets to subclass PseudoSourceValueManager,
and allocate them similarly to MachineFunctionInfo.

issue #55758

Note, this is a re-submission of D125894 with `features = ["-header_modules"]`
added to the main BUILD.bazel file.

Some functions like `stpncpy` are implemented in terms of `memset` but are not
currently using `-fno-builtin-memset`. This is somewhat hidden by the fact that
we use `-ffreestanding` globally and that `-ffreestanding` implies
`-fno-builtin` for Clang.

This patch also removes `-mllvm -combiner-global-alias-analysis` that is Clang
specific and that does not bring substantial gains on modern processors.

Also we keep `-mllvm --tail-merge-threshold=0` for aarch64 in CMakeLists.txt
but we omit it in the Bazel config. This is because Bazel consumes the source
files directly and so it can use PGO to take optimal decisions locally.

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

For https://github.com/llvm/llvm-project/commit/7d76d6095880f34914d85d876b260cc4a4ea640d

This reverts commit 5890b301 as per discussion
on the review thread: https://reviews.llvm.org/D114487#3547560.

I'm a bit confused by what's actually stored for the allocation
hints. The MIR parser only handles the "simple" case where there's a
single hint. I don't really understand the assertion in
clearSimpleHint, or under what circumstances there are multiple hint
registers.

The constructor is not used. Remove it.

This reverts commit ec4adf1f. The commit causes
clang to hang on a certain input:
```
$ cat q.cc
int f(int a, int b) {
  int c = ((unsigned char)(a >> 23) & 925);
  if (a)
    c = (a >> 23 & b) | ((unsigned char)(a >> 23) & 925) | (b >> 23 & 157);
  return c;
}

$ time ./clang-15-10515 --target=x86_64--linux-gnu -O1  -c q.cc
^C

real    0m45.072s
user    0m0.025s
sys     0m0.099s
```

The basic infinite loop is lowered to a branch to the body of the
loop, and the body containing a back edge as its terminator.

Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.

Reviewed By: rovka

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>

Add the cxx.bnf file as a dependency of custom gen commands, so that the
inc files can be rebuilt when cxx.bnf changes.

It doesn't look like we have test coverage for this at the moment :(

Avoid a behavior change when opaque pointers are enabled by default.

The FunctionTypeExtraBitfields is currently only available when the
ExceptionSpecificationType == Dynamic, which means that there is no other
way to use or extend the FunctionTypeExtraBitfields independently of the
exception specification type.

This patch adds a new field HasExtraBitfields to specify
whether the prototype has trailing ExtraBitfields.

This patch intends to be NFC and is required for future extension
and use of the ExtraBitfields struct.

Reviewed By: aaron.ballman, erichkeane

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

Reviewed By: tpopp

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

If the LHS/RHS selection operands can be cheaply concatenated back together then replace 2 x 128-bit selection nodes with 1 x 256-bit node

Addresses the regression introduced in the bug fix from rGd5af6a38

This patch updates the VPlan native path to use VPRegionBlocks for all
loops in a loop nest. Up to now, only the outermost loop used a region.

This is a step towards unifying both paths and keep things consistent
between them. It also prepares various code-gen parts for modeling the
pre-header in the inner loop vectorizer (D121624).

Reviewed By: Ayal

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