Reviewed By: RKSimon

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

An associated -W flag is needed.

This reverts commit 1d511e18.

* Remove `transform::PatternRegistry`.
* Add a new op for each currently registered pattern set.
* Change names of vector dialect pattern selector ops, so that they are consistent with the remaining code base.
* Remove redundant `transform.vector.extract_address_computations` op.

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

The report of NULL stream was removed in commit 570bf972.
The old reason is not actual any more because the checker dependencies are changed.
It is not good to eliminate a failure state (where the stream is NULL) without
generating a bug report because other checkers are not able to find it later.
The checker did this with the NULL stream pointer, and because this checker
runs now before other checkers that can detect NULL pointers, the null pointer
bug was not found at all.

Reviewed By: steakhal

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

This is the same as D100412.

We just found the same crash when we tried to compile some packages
like mariadb, php, etc.

For constraint "o", it means "A memory operand is allowed, but
only if the address is offsettable". So I think it can be handled
just like constraint "m" for RISCV target.

And we print verbose information when unsupported constraints occur.

Reviewed By: asb

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

This reverts commit 02369b75.

At the moment, live-outs used *only* for the resume values in the scalar
loop are not modeled in VPlan yet. This means first-order recurrence
recipes could be removed, when a scalar epilogue is required and the
only use of a FOR is outside the loop.

Keep treating recurrence recipes as having side-effects for now, to
avoid them being removed.

Fixes #62954.

Add a TransformInterpreterPassBase capability to generate the (shared)
module containing the transform script during the pass initialization.
This is helpful to programmatically generate the script as opposed to
parsing it from the textual module.

Reviewed By: springerm

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

This makes sure that all tests that can be vectorized in the file are
vectorized.

Fix for D151797 where the change accidentally allowed exit to
exact mode between branch instructions.

Reviewed By: dstuttard

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

This fixes PR32873 / https://github.com/llvm/llvm-project/issues/32220.

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

This brings the list of extensions supported here up to date
with what is supported by current git versions of binutils.

Also add a comment to AArch64TargetParser to remind people to
consider adding new ones to the list supported in assembly.

In the case of the "rdma" extension, there's a slight surprise:
LLVM knows of the extension under the name "rdm", while binutils
has it named "rdma". However, binutils appears to accept any
abbreviated prefix of an arch extension, so it does accept the
form "rdm" too even if it formally considers it called "rdma".

Support both spellings for the extensions here, for simplicity.

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

Reviewed By: jpienaar, burmako

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

Mixing -mfloat-abi=hard with a CPU that doesn't have floating point
registers is an error in GCC:
  cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU

Since there is code in the wild (including in clang tests) that relies
on Clang's current behaviour, emit a warning instead of an error.

Unlike the GCC error, the new warning refers to floating point
registers instead of an FPU. This is because -mfloat-abi=hard and
-march=armv8.1-m.main+mve+nofp are compatible - in that case floating
point registers are required, but an FPU is not required.

My initial thought was to use the floating point ABI calculated by
arm::getARMFloatABI() but in invalid cases which error for other
reasons the ABI is miscalculated and the warning would cause confusion.
Therefore only warn if the user specifies the float ABI explicitly.

Fixes part of https://github.com/llvm/llvm-project/issues/55755

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

If intrinsic `get_fpenv` or `set_fpenv` is lowered to the form where FP
environment is represented as a region in memory, extra moves can
appear. For example the code:

  define void @func_01(ptr %ptr) {
    %env = call i256 @llvm.get.fpenv.i256()
    store i256 %env, ptr %ptr
    ret void
  }

produces DAG:

  ch = get_fpenv_mem ch, memory_region
  val: i256, ch = load ch, memory_region
  ch = store ch, ptr, val

In this case the extra moves can be avoided if `get_fpenv_mem` got
pointer to the memory where the FP environment should be finally placed.

This change implement such optimization for this use case.

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

All vector transform ops are now `PatternDescriptorOpInterface` ops that merely select the patterns. The patterns are applied by the `apply_patterns` op. This is to ensure that ops are properly tracked. (TrackingListener is used in the implementation of `apply_patterns`.) Furthermore, handles are no longer invalidated when applying patterns in the vector tests.

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

This commit ensures that llvm-extract does not copy all IFuncs into the
resulting modules. Before this change, ifuncs were not modified which
could cause the emission unexpected IR files.

Reviewed By: darthscsi

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

Patterns should be selected by adding ops that implement `PatternDescriptorOpInterface` to the region of `apply_pattern` ops. Such ops can have operands, allowing for pattern parameterization. The existing way of selecting patterns from the PatternRegistry is deprecated.

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

This reverts commit 1ebe0601.

I've been informed the old way was documented in the psABI.

CMake older than 3.20.0 is no longer supported.
This removes work-arounds for no longer supported versions.

Reviewed By: #libc, jloser, philnik

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

When splitting a simm32 into LUI+ADDI(W). Subtract Lo12 from Val
to calculate Hi20. This replaces the old method of adding 0x800 to
Val. This change makes the math the reverse of how the LUI+ADDI(W)
create the immediate.

Due to the nature of WebAssembly, it's always better to keep
rotates instead of trying to optimize it. Commit 9485d983
disabled the generation of fsh for rotates, however these
tests ensure that future changes don't change the behaviour for
the Wasm backend that tends to have different optimization
requirements than other architectures. Also see:
https://github.com/llvm/llvm-project/issues/62703

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

Implements parts of P1614R2 `operator<=>` for `queue`

Reviewed By: #libc, Mordante

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

This patch forbids to write comment to BMIs for C++20 Named Modules.
Originally I thought this was helpful for language services like clangd.
But I found clangd don't want the BMI to contain comments actually. So
it is meaningless for C++20 Named Modules to keep such comments in
their BMI.

It is simple to enable this when someday we found we want this actually.

Similar to AArch64,AVR,PowerPC: 9e2d100e.

Similar to 49488490.

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

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

Reviewed By: Patryk27, jacquesguan

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

This reverts commit 50a2341f.

This results in buildbot fail.

A CHECK() was firing when a call to the PACK intrinsic does not have a
VECTOR= argument and at least one dimension of the shape of the ARRAY=
argument could not be determined.  The CHECK was inappropriate, since
this can of course happen, such as when that argument is the result
of the SPREAD() intrinsic with non-constant DIM= or NCOPIES= arguments.
Replace with an if() statement.

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

Since vfclass intruction will only set one single bit in the result, so if we only want to check 1 fp class, we could use vmseq to do it.

Reviewed By: craig.topper

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

- add the `from_range_t` constructors and the related deduction guides;
- add the `push_range` member function.

(Note: this patch is split from https://reviews.llvm.org/D142335)

Reviewed By: #libc, ldionne

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