With recent fixes to the dataflow in place, we now never pass
Strict=true to isCompatible, so remove the parameter completely.

Reviewed By: reames

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

This test is passing now because of D124017 and D123949.

Reviewed By: DiggerLin

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

Move from the old CreateXYZ() to the new FoldXYZ() mechanism.

This change is likely NFC in practice, because I don't think that
the places using InstSimplifyFolder use insertvalue/extractvalue.

The standard says:
The optional requires-clause ([temp.pre]) in an init-declarator or
member-declarator shall be present only if the declarator declares a
templated function ([dcl.fct]).

This implements that limitation, and updates the tests to the best of my
ability to capture the intent of the original checks.

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

Need to check if the reduction is still (not)cmp-select pattern min/max
reduction to avoid compiler crash during building list of reduction
operations. cmp-sel pattern provides 2 reduction operations, while
intrinsics - just one.

The title says it all.

Reviewed By: thakis

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

This patch allows systems to build the llvm-project with the devtoolset-11
toolchain.

Reviewed By: phosek

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

If we're using shift pairs to mask, then relax the one use limit if the shift amounts are equal - we'll only be generating a single AND node.

AArch64 has a couple of regressions due to this, so I've enforced the existing one use limit inside a AArch64TargetLowering::shouldFoldConstantShiftPairToMask callback.

Part of the work to fix the regressions in D77804

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

This allows controlling the current_version linker property on Apple
platforms.

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

Previously the Expr returned by getOperand() was actually the
subexpression common to the "ready", "suspend", and "resume"
expressions, which often isn't just the operand but e.g.
await_transform() called on the operand.

It's important for the AST to expose the operand as written
in the source for traversals and tools like clangd to work
correctly.

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

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

Add a new TargetRegisterInfo hook to allow targets to tweak the
priority of live ranges, so that AllocationPriority of the register
class will be treated as more important than whether the range is local
to a basic block or global. This is determined per-MachineFunction.

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

This updates 5de12bb7
to not link with the dylib since that does not include
the tablegen library.

Should fix flang dylib build failures:
https://lab.llvm.org/buildbot/#/builders/177/builds/5120

Those helpers model properties of a user and they should also be
available to non-recipe users. This will be used in D123537 for a new
exit value user.

Reviewed By: Ayal

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

Extends the cleanup in D125713 to IsWasm64.

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

This is (IMHO) cleaner and (objectively) more strongly typed than using strings.

A follow-on patch will do the same for IsWasm64.

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

We already use combineAddOrSubToADCOrSBB to fold extended EFLAGS results into ISD::ADD/SUB ops as X86ISD::ADC/SBB carry ops.

This patch extends this to also try to fold EFLAGS results with X86ISD::ADD/SUB ops

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

The vload*_half* and vstore*_half* builtins do not require the
cl_khr_fp16 extension: pointers to `half` can be declared without the
extension and the _half variants of vload and vstore should be
available without the extension.

This aligns the guards for these builtins for
`-fdeclare-opencl-builtins` with `opencl-c.h`.

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

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

JumpThreading intentionally does not force updating of the DT
during optimization, because this may be expensive when many CFG
updates and DT calculations are interleaved.

We shouldn't be fetching the DT just for the purpose of calling
isGuaranteedNotToBeUndefOrPoison(), especially as DT availability
doesn't even show benefit in tests.

this review is extracted from D86539.

1. Rename AccelTableKind to DwarfLinkerAccelTableKind
   (to differentiate from AccelTableKind from CodeGen/AsmPrinter/DwarfDebug.h)

2. Add None value to the DwarfLinkerAccelTableKind.

3. added 'None' value for 'accelerator' option of dsymutil.

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

[SROA] Avoid postponing rewriting load/store by ignoring lifetime intrinsics in partition's promotability checking

This patch fixes a bug that generates unnecessary packing/unpacking structure code because of incorrectly handling lifetime intrinsic.
For example, a partition of an alloca may contain many slices:
```
Partition [0, 4):
  Slice0: [0, 4) used by: load i32 addr;
  Slice1: [0, 4) used by: store i32 v, addr;
  Slice2: [0, 16) used by lifetime.start(16, addr);
```
When SROA determines if the partition can be promoted, lifetime.start is currently treated as a whole alloca load/store, so Slice0 and Slice1 cannot be promoted at this attempt,
but the packing/unpacking code for Slice0 and Slice1 has been generated.
After rewrite lifetime.start/end intrinsic, SROA tries again with Slice0 and Slice1 and finally promotes them, but redundant packing/unpacking code remaining in the IRs.
This patch changes promotability checking to ignore lifetime intrinsic (they will be rewritten to correct sizes later), so we can promote the real users (load/store) at the first attempt with optimal code.

Reviewed By: nikic

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

The support for this has been added by 946311b8
but then ignored by bc22b5c9.

This enables one to write generic code that can be instantiated for both
specific operation classes and the common base class without
specialization. Examples include functions that take/return ops, such
as:

```mlir
template <typename FnTy>
void applyIf(FnTy &&lambda, ...) {
  for (Operation *op : ...) {
    auto specific = dyn_cast<function_traits<FnTy>::template arg_t<0>>(op);
    if (specific)
      lambda(specific);
  }
}
```

that would otherwise need to rely on template specialization to support
lambdas that take specific operations and those that take `Operation *`.

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

Reviewed by: rriddle

This patch uses VP_REDUCE_AND and VP_REDUCE_OR to replace VP_REDUCE_SMAX,VP_REDUCE_SMIN,VP_REDUCE_UMAX and VP_REDUCE_UMIN for mask vector type.

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

This seems to be a copy-paste from the similar zlib detection code.

Patch By: sthibaul

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

This is the second patch to enable the XCOFF64 object writer.

Reviewed By: jhenderson, shchenz

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

We do have a non-trivial implementation for binaryXor() now.

This allows us to compute known high bits. It's not optimal, but
better than nothing.

This patch adds a simple test which demonstrates a miscompilation of
16-byte-aligned scalar (non-RVV) objects when combined with RVV stack
objects.

The RISCV stack is assumed to be aligned to 16 bytes, and this is
guaranteed/assumed to be true when setting up the stack. However, when
the stack contains RVV objects, we decrement the stack pointer by some
multiple of vlenb, which is only guaranteed to be aligned to 8 bytes.
This means that non-RVV objects specifically requiring 16-byte alignment
fall through the cracks and are misaligned. Objects requiring larger
alignment trigger stack realignment and thus should be okay.

Reviewed By: craig.topper

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

The documentation for this specifically mentions that this should not
happen. We could think about adding target hooks to permit it (and how
to merge IDs) in the future if that is desirable.

This specific test case was merging a scalable-vector slot into a
non-scalable one and dropping the notion of scalability, meaning we
failed to allocate enough stack space for the object.

Reviewed By: arsenm, MaskRay, sdesmalen

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