Three unrelated, small improvements:

* `test_macros.h` was incorrectly saying `__has_include("<version>")`
instead of `__has_include(<version>)`.
+ This caused `<ciso646>` to always be included (noticed because MSVC's
STL emitted a deprecation warning).
  + I searched all of LLVM and found no other occurrences.
* `thread.condition.condvarany/wait_for_pred.pass.cpp` forgot to test
anything.
  + I followed what `wait_for.pass.cpp` is testing.
* Uncomment spaceship test coverage.

We were missing the PoisonOnly argument (so Depth + 1 was being used instead and the default Depth = 0 argument then being silently used)

Fixes #94145 and serves as the test case for 9e22c7a0

This reverts commit de37c06f to
de37c06f

It still breaks EXPENSIVE_CHECKS build. Sorry.

Port selection dag isel to new pass manager.
Only `AMDGPU` and `X86` support new pass version. `-verify-machineinstrs` in new pass manager belongs to verify instrumentation, it is enabled by default.

We can convert this to a select based on the `(icmp eq X, C)`, then
constant fold the addition the true arm begin `(add C, (sext/zext 1))`
and the false arm being `(add X, 0)` e.g

    - `(select (icmp eq X, C), (add C, (sext/zext 1)), (add X, 0))`.

This is essentially a specialization of the only case that sees to
actually show up from #89020

Closes #93840

[mlir][bazel] Add bazel build support for https://github.com/llvm/llvm-project/commit/2b2ce50fe843b5b550806a0ab15b06cd5c405d48 (#94126)

Also drop errant header include from `Linalg` dialect into
`Dialect/SCF/Transforms/TileUsingInterface.cpp`

in `atomic::wait`, when we call the platform wait ulock_wait , we are
using UL_COMPARE_AND_WAIT. But we should use UL_COMPARE_AND_WAIT64
instead as the address we are waiting for is a 64 bit integer.

fixes https://github.com/llvm/llvm-project/issues/85107

It is rather hard to test directly because in `atomic::wait`, before
calling into the platform wait, our c++ code has some poll logic which
checks the value not changing. Thus in this patch, the test is using the
internal function.

This commit adds an API (`tileAndFuseConsumerOfSlice`) to fuse consumer to a producer within
scf.for/scf.forall loop.

To support this two new methods are added to the `TilingInterface`
- `getIterationDomainTileFromOperandTile`
- `getTiledImplementationFromOperandTile`.

Consumer operations that implement this method can be used to be fused with tiled producer operands in a manner similar to (but essentially the inverse of) the fusion of an untiled producer with a tiled consumer.

Note that this only does one `tiled producer` -> `consumer` fusion. This could be called repeatedly for fusing multiple consumers. The current implementation also is conservative in when this kicks in (like single use of the value returned by the inter-tile loops that surround the tiled producer, etc.) These can be relaxed over time.

Signed-off-by: Abhishek Varma <abhvarma@amd.com>

---------

Signed-off-by: Abhishek Varma <abhvarma@amd.com>
Signed-off-by: Abhishek Varma <avarma094@gmail.com>
Co-authored-by: cxy <chenxunyu1993@gmail.com>

Since #93182 we can now call computeKnownBits inside getValidMaximumShiftAmount to determine the bounds of the shift amount ensuring that it wasn't poison, meaning if we did freeze the ahift amount, isGuaranteedNotToBeUndefOrPoison would then fail as we can't call computeKnownBits through FREEZE for potentially poison values.

I'm still reducing a decent test case but wanted to get the buildbot fix ASAP.

The target include directory should always  come first,
since the regular includes are dependent on it

In order to make the behavior of the libc++ restarter more visible
to users, this change creates a check run on the considered workflow
to let users know what action, if any, was taken

[DAG] Replace getValid*ShiftAmountConstant helpers with getValid*ShiftAmount helpers to support KnownBits analysis (#93182)

The getValidShiftAmountConstant/getValidMinimumShiftAmountConstant/getValidMaximumShiftAmountConstant helpers only worked with constant shift amounts, which could be problematic after type legalization (e.g. v2i64 might be partially scalarized or split into v4i32 on some targets such as 32-bit x86, Thumb2 MVE).

This patch proposes we generalize these helpers to work with ConstantRange+KnownBits if a scalar/buildvector constant isn't available.

Most restrictions are the same - the helper fails if any shift amount is out of bounds, getValidShiftConstant must be a specific constant uniform etc.

However, getValidMinimumShiftAmount/getValidMaximumShiftAmount now can return bounds values that aren't values in the actual data, as they are based off the common KnownBits of every vector element.

This addresses feedback on #92096

Adds a split-dwarf test for DWARF4 with multiple CUs.

For interleave groups we only create a pointer for the start of the
interleave group, not all original loads/stores. Mark single-use ops
feeding interleave group mem ops as free when vectorizing.

Proof: https://alive2.llvm.org/ce/z/J7GBMU

Same as https://github.com/llvm/llvm-project/pull/92753, the types of
LHS and RHS in shift nodes may differ.
+ When VT is smaller than ShiftVT, it is safe to use trunc.
+ When VT is larger than ShiftVT, it is safe to use zext iff
`is_zero_poison` is true (i.e., `opcode == ISD::CTTZ_ZERO_UNDEF`). See
also the counterexample `src_shl_cttz2 -> tgt_shl_cttz2` in the alive2
proofs.

Fixes issue
https://github.com/llvm/llvm-project/pull/85066#issuecomment-2142553617.

Fixes #91831

This commit relaxes the verifier of
`bufferization.materialize_in_destination` such that mixed
static/dynamic dimensions are allowed for the source and destination
operands. E.g., `tensor<5xf32>` and `tensor<?xf32>` are now compatible,
but it is assumed that the dynamic dimension is `5` at runtime.

This commit fixes #91265.

A follow up to #92953. Suggested in https://github.com/llvm/llvm-project/pull/92953#issuecomment-2143274065

This helps getTemplateInstantiationArgs() to properly recover template
arguments of an enclosing concept Decl.

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

from PEP8
(https://peps.python.org/pep-0008/#programming-recommendations

):

> Comparisons to singletons like None should always be done with is or
is not, never the equality operators.

Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>

This patch converts `zext nneg` to `sext` on RISCV to use free sext.

---------

Co-authored-by: Thorsten Schütt <schuett@gmail.com>

When the orphan section is placed after i, incrementing then
decreamenting is quite difficult to understand. Simplify the code to a
single loop to make the intention clearer.

Simplify the loop that considers sections of the same proximity. The two
involved conditions are due to:

* https://reviews.llvm.org/D111717 ("[ELF] Avoid adding an orphan section to a less suitable segment") and
* https://reviews.llvm.org/D112925 ("[ELF] Better resemble GNU ld when placing orphan sections into memory regions")

Our pattern previously checked for the merge operand being undef.