The legacy PM allowed you to set a custom inliner threshold via
  builder.Inliner = llvm::createFunctionInliningPass(inline_threshold);

This allows the same thing to be done with the new PM optimization pipelines.

Reviewed By: asbirlea

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

Reviewed By: awarzynski, asbirlea

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

See [1] for background.

Some people have complained that `opt -passes=instcombine` is a lot more typing than `opt -instcombine`.
As a compromise that nobody has objected to in [1], allow `opt -p instcombine`.

[1] https://discourse.llvm.org/t/rfc-legacy-opt-pass-syntax-with-new-pass-manager/65863

Reviewed By: bjope, asbirlea

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

Context: I plan on using this change primarily downstream in the apple
fork of llvm to track swift module loading time.

Reviewed By: clayborg, tschuett

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

Remove the `--src-root` option from the deprecated llvm-config tool.
None of the llvm-project projects use this option anymore. The value
was only meaningful for in-tree use and usually became no longer correct
once LLVM was installed -- either because it was built in a temporary
directory, or installed from a binary package and built on a different
system entirely.  Therefore, third-party tools could not have been
relying on it anyway.

The LLVM_SRC_ROOT #define is left intact, as it is used to compute
includedir when llvm-config is used in-source.

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

This patch should land before D137136 to make sure that the leak sanitizer allocator works correctly. This patch is NFC without D137136.

Reviewed By: vitalybuka

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

For some auto-generated sources, we have a huge number of critical
edges (like from switch statements). We have seen instance of 183777
critical edges in one function.

After we split the critical edges in PGO instrumentation/profile-use
pass, the CFG is so large that we have compiler time issues in
downstream passes (like in machine CSE and block placement). Here I
add a threshold to skip PGO if the number of critical edges are too
large.

The threshold is large enough so that it will not affect the majority
of PGO compilation.

Also sync the logic for skipping instrumentation and profile-use. I
think this is the correct thing to do.

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

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

Enable in clang: -Xclang -fexperimental-assignment-tracking
Enable in llvm tools: -experimental-assignment-tracking

When assignment tracking is enabled in clang it will pass on the flag to enable
the feature in lllvm. It's undefined behaviour to read IR that contains
assignment tracking metadata without specifying the feature flags.

Tests will come with later patches that add assignment tracking features.

Reviewed By: jmorse

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

Reviewed By: ftynse

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

Fix typo pointed out by Roman Divacky.

There should be no functional change, as the rest of the code will
return nullptr for undef anyway. The condition is just there for
clarity.

Switch to using an optional group in the assembly format instead of a
custom directive. There's no change to the actual printed format.

Reviewed By: vzakhari

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

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