This patch moves the 1:N type mapping into its own classes to allow better code reuse in D137100.

Reviewed By: ftynse

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

This patch fixes the 6 amdgpu buildbot lit test failures
introduced by https://reviews.llvm.org/D135444.
      libomptarget :: amdgcn-amd-amdhsa :: mapping/reduction_implicit_map.cpp
      libomptarget :: amdgcn-amd-amdhsa :: offloading/cuda_no_devices.c
      libomptarget :: amdgcn-amd-amdhsa :: offloading/target-teams-atomic.c
      libomptarget :: amdgcn-amd-amdhsa-LTO :: mapping/reduction_implicit_map.cpp
      libomptarget :: amdgcn-amd-amdhsa-LTO :: offloading/cuda_no_devices.c
      libomptarget :: amdgcn-amd-amdhsa-LTO :: offloading/target-teams-atomic.c

Reviewed By: jhuber6

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

Since we now only support Visual Studio 2019 16.7 and newer, we're able to use the /Zc:preprocessor flag that turns on the standards-conforming preprocessor. Among other things, it correctly expands __VA_ARGS__. This enables removal of some boilerplate in D135128.

Reviewed By: Bigcheese, thieta

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

Remove the colon from the CHECK line for the output of the file command.
On macOS and Linux, the file command uses a colon as the separator
between the path and the file type, but gnuwin32's file command uses a
semicolon.

Currently `-pass-pipeline` can be specified multiple times and mixed
with the individual `-pass-name` options. Removing this feature will
allow for including the pipeline anchor as part of the option
argument (see D134900).

Reviewed By: rriddle

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

These are test updates required for D135745, which disallows mixing
`-pass-pipeline` and the individual `-pass-name` options.

Reviewed By: rriddle, mehdi_amini

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

The AsyncInfoTy should be created in the same device as the async operation will be issued. In omp_target_memcpy, the AsyncInfoTy for the host to destination device transfer was created referring to the source device.

Reviewed By: tianshilei1992

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

When a fir.dispatch is done with a NOPASS type-bound
procedure, the object in fir.dispatch is just used to gather the vtable.
Therefore, no transformation is done on it and the original entity
is used. The current code generation didn't expect the entity to be an array.
This patch update the code generation to be able to retrieve the vtable
accordingly.

Reviewed By: PeteSteinfeld

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

Some host targets are managing to get through MIR parsing
without constructing their MachineFunctionInfo.

Fixes at least SystemZ and SPARC (issue 58768)

Reviewed By: jeffbailey

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

Reviewed By: jeffbailey

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

Reviewed By: jeffbailey

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

Reviewed By: jeffbailey

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

We can cost them the same way as a scalable masked load/store. By hitting the default path, we were costing them as if they were being scalarized. This is a significant over estimate.

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

Buildbot link: https://lab.llvm.org/buildbot/#/builders/30/builds/27812

This change make sure that ExecutionEngine's pass pipeline is identical to one
used by clang. Previously, SLPVectorization was not enabled which caused
differences in code...

...generation.

Reviewed By: ftynse

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

D121929 happens to cause CodeGen/MIR/AArch64/mirnamer.mir to fail due
to a hash collision caused by adding two extra opcodes. The collision
is only in the top 19 bits of the hashed opcode so fix this by just
using the whole hash (in fixed width hex for consistency) instead of
the top 5 decimal digits.

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

Currently MachineCSE forbids PRE when the instruction reads a physical
register. Relax this so that it's allowed when the value being read is
the same as what would be read in the place the instruction would be
hoisted to.

This is being done in preparation for adding FPCR handling to the
AArch64 backend, in order to prevent it to from worsening the
generated code, but for targets that already have a similar register
it should improve things.

This patch affects code generation in several tests. The new code
looks better except for in Thumb2/LowOverheadLoops/memcall.ll where
we perform PRE but the LowOverheadLoops transformation then undoes
it. Also in AMDGPU/selectcc-opt.ll the CHECK makes things look worse,
but actually the function as a whole is better (as a MOV is PRE'd).

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

We should still be able to fold comparisons based on ranged in
this case.

The Assignment Tracking debug-info feature is outlined in this RFC:

https://discourse.llvm.org/t/
  rfc-assignment-tracking-a-better-way-of-specifying-variable-locations-in-ir

Add documentation outlining the intent and design.

This is a corrected version of:
bc886e9b

I made a copy-paste error that created an "add" instead of the
intended "sub" on that attempt. The regression tests showed the
bug, but I overlooked that.

As I said in a comment on issue #58717, the bug reports resulting
from the botched patch confirm that the pattern does occur in
many real-world applications, so hopefully eliminating the multiply
results in better code.

I added one more regression test in this version of the patch,
and here's an Alive2 proof to show that exact example:
https://alive2.llvm.org/ce/z/dge7VC

Original commit message:

This is a sibling to:
6064e92b
...but we canonicalize the shl+add to shl+xor,
so the pattern is different than I expected:
https://alive2.llvm.org/ce/z/8CX16e

I have not found any patterns that are safe
to propagate no-wrap, so that is not included
here.

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

Using a DebugVariable as the set key rather than std::pair<DIVariable *,
DIExpression *> ensures we don't accidently confuse multiple instances of
inlined variables.

Reviewed By: jryans

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

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

This crash was due to incorrect usage of `hasTensorSemantics`, which has changed recently with DestinationStyleOpInterface. An op has tensor semantics if all of its inits and inputs are tensors. Previously, only inits needed to be tensors.

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

The test crashes with an assert in unswitchNontrivialInvariants.

Follow-on to:
ec0b406e

This should prevent crashing for example like issue #58552
by not matching a select-of-vectors-with-scalar-condition.

The test that shows a regression seems unlikely to occur
in real code.

This also picks up an optimization in the case where a real
(bitwise) logic op is used. We could already convert some
similar select ops to real logic via impliesPoison(), so
we don't see more diffs on commuted tests. Using commutative
matchers (when safe) might also handle one of the TODO tests.

Similar to 29661fe9 - there are matching
deficiencies and a potential crash lurking in
these patterns.

When resolving absolute addresses for DW_OP_addr or DW_OP_addrx, these are always load addresses rather than file addresses in wasm.

Reviewed By: DavidSpickett

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

gnu17 and earlier modes automatically expose several POSIX C APIs, and
this was accidentally disabled for gnu2x in
7d644e12.

This restores the behavior for gnu2x mode (without changing the
behavior in C standards modes instead of GNU modes).

Fixes #56607

Splatting the first vector element of the result of a BinOp, where any of the
BinOp's operands are the result of a first vector element splat can be simplified to
splatting the first vector element of the result of the BinOp

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

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

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

This test was introduced by a667aa4d. It
assumes that it runs on x86_64 on linux, so require that for the test.

This prevents duplicates to be pushed into the stack and hypothetically
should reduce memory footprint on ugly cornercases with multiple repeating
duplicates in 'and' tree.

Fixes https://github.com/clangd/clangd/issues/1082

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

It can be useful to external users as well for detecting if there were any changes in IR between passes.

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

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

In ELF, symbols of type STT_GNU_IFUNC need to be resolved by calling the
function at the symbol's address. This is implemented by adding special
stubs for all symbols of that type.

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

Use DL-aware ConstantFoldCompareInstOperands() API instead of
ConstantExpr API. The practical effect of this is that SCCP can
now fold comparisons that require DL.