This moves mutation entirely out of the main algorithm.

The immediate trigger is that we hit another case of the same issue I thought we'd fixed in 72925d98. It turns out we hadn't considered the cross block case.

As a brief summary, the issue being fixed is that if we mutate a previous vsetvli in phase 3, there's a possibility that some later use of that vsetvli changes "compatibility". In the cross_block_mutate test, this later vsetvli occurs in another block (and is thus visit order dependent too!). This causes us to fail strict asserts. (To be explicit, the current on by default workaround should compensate. It's only when we turn that off that we have problems.)

Now, I want to explicitly call out an alternate workaround. We could leave the mutation in phase 3, and simplify restrict it to the case where the previous vsetvli's GPR result is unused. That covers the case we've actually seen. (I'll note that codegen regressions with a simple form of this were significant. We might have to check specifically for the use outside block case to keep them reasonable, which complicates the workaround slightly.)

Personally, I'm at the point where I want the mutation pulled out just for robustness sake. I'm worried there's yet one more form of this bug we haven't thought about.

The other motivation for this change is that it does give us a couple of minor codegen wins. None appear to be hugely significant, but improvements never hurt right?

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

This appears to have been added in a follow-up commit that I missed.

This reverts commit 232bf818.

It broke the sanitize buildbot: https://lab.llvm.org/buildbot/#/builders/5/builds/24074

It also reproduces on Windows debug builds as a crash.

Warns when end-of-file is reached without seeing all matching
'omp end declare target' directives. The diagnostic shows the
location of the related begin directive.

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

Summary:
I added the `-Xoffload-linker` flag and did not provide additional
documentation. This patch adds it.

A later change will add a 3rd user, so factoring out the common code
seems useful.

Reorganizing the executeInWaterfallLoop causes some more COPYs to be
generated, but those all fold away during instruction selection.
Generating the comparisons uses generic instructions over machine
instructions now which admittedly shouldn't make a difference
(though it should make it easier to move the waterfall loop generation
to another place).

(Resubmit with missing test added.)

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

This reverts commit 2a28467e.

Reland "[llvm-pdbutil] Add options to only dump symbol record at specified offset and its parents or children with spcified depth."

This reverts commit cfb4e782.

This patch fixes:

  .../llvm-project/lldb/source/Host/common/PseudoTerminal.cpp:106:20:
  error: unused function 'use_ptsname' [-Werror,-Wunused-function]

This commit fixes `Tensor_InsertSliceOp` `sizes` inputs/attributes
description.

Before this commit, the description says the `sizes` inputs/attributes
denote the size of the return type. But according to the
`InsertSliceOpConstantArgumentFolder` in
`lib/Dialect/Tensor/IR/TensorOps.cpp`, the `sizes` inputs/attributes
actually denote the size of the source type.

I had an off-line discussion with the authors of `TensorOps.td` and
`TensorOps.cpp`. We concluded that it was a typo in the Op description.

This commit updates the Op description to match the actual usage.

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

A later change will add a 3rd user, so factoring out the common code
seems useful.

Reorganizing the executeInWaterfallLoop causes some more COPYs to be
generated, but those all fold away during instruction selection.
Generating the comparisons uses generic instructions over machine
instructions now which admittedly shouldn't make a difference
(though it should make it easier to move the waterfall loop generation
to another place).

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

This adds support for pointer types for `atomic xchg` and let us write
instructions such as `atomicrmw xchg i64** %0, i64* %1 seq_cst`. This
is similar to the patch for allowing atomicrmw xchg on floating point
types: https://reviews.llvm.org/D52416.

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

Update test to check MIR after finalize-isel instead of debug output.

This is of course not the only place we should preserve FMF, but
it's the most obvious one.

Reviewed By: frasercrmck

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

I think we need to be sure the load isn't volatile before we
duplicate and shrink it.

Reviewed By: spatel

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

This fixes https://github.com/llvm/llvm-project/issues/53998
and displays correct information in obj2yaml for SHN_MIPS_*
sections according to
https://refspecs.linuxfoundation.org/elf/mipsabi.pdf

Reviewed By: jhenderson, MaskRay

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

As @rsmith commented on https://reviews.llvm.org/D111548: "That looks like it's
simply a bug as far as I can tell, and that call can be removed. MS attributes
will be parsed as part of the decl specifier sequence as needed and don't need
to be parsed as declaration attributes."

Reviewed By: aaron.ballman

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

This is a straight forward extension of the PRE transform introduced in D124869 to handle the VLMAX case.

The test changes here look quite positive. This surprised me until I realized that all the tests are using @llvm.vscale to figure out the VLMAX, not the llvm.riscv.vsetvlmax intrinsic. If they'd used the later, these would have been full redundancy cases and fully handled by the data flow. I'm not really sure if use of vscale here is representative or not. If it is, we should probably look at using VSETVLI to lower vscale rather than a raw read of vlenb and some math.

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

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

Using 64-bit integer/float type in interface storage classes would
require Int64/Float64 capability, per the Vulkan spec:

```
shaderInt64 specifies whether 64-bit integers (signed and unsigned) are
supported in shader code. If this feature is not enabled, 64-bit integer
types must not be used in shader code. This also specifies whether
shader modules can declare the Int64 capability. Declaring and using
64-bit integers is enabled for all storage classes that SPIR-V allows
with the Int64 capability.
```

This is different from, say, 16-bit element types, where:

```
shaderInt16 specifies whether 16-bit integers (signed and unsigned) are
supported in shader code. If this feature is not enabled, 16-bit integer
types must not be used in shader code. This also specifies whether
shader modules can declare the Int16 capability. However, this only
enables a subset of the storage classes that SPIR-V allows for the Int16
SPIR-V capability: Declaring and using 16-bit integers in the Private,
Workgroup (for non-Block variables), and Function storage classes is
enabled, while declaring them in the interface storage classes (e.g.,
UniformConstant, Uniform, StorageBuffer, Input, Output, and
PushConstant) is not enabled.
```

Reviewed By: hanchung

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

These attributes can carry useful information, e.g., pipelines
might use them to organize and chain patterns.

Reviewed By: hanchung

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

Uncomment the tests to ensure `std::ranges::rbegin` and friends are indeed
customization points objects.

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

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

Rely on lit substitution to provide the path to llvm-windres instead
of redundantly calling which(1) with the subtituted absolute path.
This fixes test failure on the happy systems without which(1) installed.

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

This patch adds support for obtaining inverse of a relation.

Reviewed By: ftynse

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

This patch adds support for obtaining a set corresponding to the domain/range
of the relation.

Reviewed By: ftynse

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

When expanding VP reductions to non VP-code, the reduction pass was
ignoring the mask before. Fix this by keeping the mask and selecting
neutral elements where the mask is zero.

Reviewed By: frasercrmck

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

Once we move off entirely from the legacy testing framework, this will
allow removing a bunch of code.

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

This would allow more AST nodes being preserved for broken code, and
have a more consistent valid bit for ref-type var decl (currently, a
ref-type var decl with a broken initializer is valid).

Per https://reviews.llvm.org/D76831#1973053, the initializer of a variable
should play no part in its "invalid" bit.

Reviewed By: sammccall

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

Virtually all LLVM tools accept a `-o` flag, so add one. This will make it
possible to possibly add a --write-if-changed flag later. It also makes it
so that the file isn't partially written if the tool oesn't run successfully.

Marking --grammar as `Required` allows removing some manual
verification code for it.

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

Caught with D125604.

Reviewed By: antiagainst

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

Reviewed By: spatel

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

PR/55600

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

Test for D126353

This adds more of the tests for the first 100 DRs in C and updates
their status on the status page.

Forgot to add this to f3c1d281