We were dropping the flags and thus blocking contract into potential
fadd users. GlobalISel was already preserving the flags here.

https://reviews.llvm.org/D155443

Prepare for new lowering strategies because we somehow didn't have
enough of them already.

This mostly manifested as broken constant folding. This was
mishandling the dynamic denormal mode. It was also mishandling literal
signaling nans, such that they would also be treated as poison.

https://reviews.llvm.org/D155437

Before this patch, the only way to generate streaming-compatible code
was to use the `-force-streaming-compatible-sve` flag, but the compiler
should also avoid the use of instructions invalid in streaming mode
when a function has the aarch64_pstate_sm_enabled/compatible attribute.

Reviewed By: paulwalker-arm, david-arm

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

This reverts commit 31263211.

Reason: Broke the ASan Windows bot: https://reviews.llvm.org/rG31263211c6a4ef454216f2edbf9b2083a4c1474d

This fixes sinking a VGPR def out of a loop past the reconvergence
point at the SI_END_CF. There was a prior fix which introduced
blockPrologueInterferes (D121277) to fix the same basic problem for
the post RA sink. This also had the special case isIgnorableUse case
which was incorrect, because in some contexts the exec use is not
ignorable.

I'm thinking about a new way to represent this which will avoid
needing hasIgnorableUse and isBasicBlockPrologue, which would function
more like the exception handling.

Fixes: SWDEV-407790

https://reviews.llvm.org/D155343

Reorder VPlan transforms slightly so they are all grouped together,
after disabling Value -> VPValue lookup. In terms of codegen impact,
this should be NFC modulo a small number of instruction reorderings.

Preparation to split up tryToBuildVPlanWithVPRecipes in a follow-up.

Reviewed By: Ayal

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

Revert "Revert "Revert "[MemCpyOpt] implement single BB stack-move optimization which unify the static unescaped allocas"""

This reverts commit b02d349c.

At the moment, SME-to-LLVM lowerings rely entirely on
`LLVMTypeConverter`. This patch introduces a dedicated `TypeConverter`
that inherits from `LLVMTypeConverter` (it will also be used when
lowering ArmSME Ops to LLVM).

The new type converter merely disables lowerings for `VectorType` to
prevent 2-d scalable vectors (common in the context of ArmSME), e.g.

   `vector<[16]x[16]xi8>`,

entering the LLVM Type converter. LLVM does not support arrays of
scalable vectors and hence the need for specialisation. In the case of
SME such types are effectively eliminated when emitting LLVM IR
intrinsics for SME.

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

No need to insert a bitcast.

Change the assertion to check the value type instead of the pointee
type. To facilitate this, store GlobalVariable* instead of Constant*
in the map.

Add a new FirOpBuilder constructor to propagate the fast math flag
from an operation. Use this constructor in the LowerHLFIRIntrinsics
pass.

This fixes the performance issue with the hlfir intrinsics flow
for polyhedron/test_fpu2.

Reviewed By: tblah, vzakhari

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

If the size of one of the operand arrays is not known at compile
time, do not issue a size mismatch error sinc they could match at
runtime.

Fixes the compilation error in polyhedron/induct2.

Reviewed By: tblah, vzakhari

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

Currently we just bypass singleton phis, however we know that
in order to create the phi of ops all phis must be in the same block.
Therefore if one phi is a singleton then the rest are as well.

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

Some of the test expectation were incorrectly changed in
23c21759. Regenerate the tests.

Without targets registered gives: "error: MS-style inline assembly is not
available: Unable to find target for this triple (no targets are registered)"

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

Fields are imported first and reordered for correct layout.
For partially imported record, layout computation is incorrect.

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

These values don't propagate to the output; they are always replaced with a subsequent shuffle
or insertelement.
Tested equivalence with Alive2, e.g., https://alive2.llvm.org/ce/z/fj4s78.

And change 'using namespace llvm::LoongArch' to 'namespace LoongArch {'
to simplify the code a little bit.

This patch adds a pass '-allocate-sme-tiles' to the ArmSME dialect that
implements allocation of SME ZA tiles.

It does this at the 'func.func' op level by replacing
'arm_sme.get_tile_id' ops with 'arith.constant' ops that represent the
tile number. The tiles in use in a given function are tracked by an
integer function attribute 'arm_sme.tiles_in_use' that is a 16-bit tile
mask with a bit for each 128-bit element tile (ZA0.Q-ZA15.Q), the
smallest ZA tile granule. This is initialized on the first
'arm_sme.get_tile_id' rewrite and updated on each subsequent rewrite.
Mixing of different element tile types is supported.

Section B2.3.2 of the SME spec [1] describes how the 128-bit element
tiles overlap with other element tiles.

Depends on D154941

[1] https://developer.arm.com/documentation/ddi0616/aa

Reviewed By: awarzynski

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

A similar assumption as for the x^x case also existed for the absorber
case, which lead to a stage2 miscompile. That assumption is not fixed.

-----

Support replacement of operands not only in the immediate
instruction, but also instructions it uses.

To the most part, this extension is straightforward, but there are
two bits worth highlighting:

First, we can now no longer assume that if the Op is a vector, the
instruction also returns a vector. If Op is a vector and the
instruction returns a scalar, we should consider it as a cross-lane
operation.

Second, for the x ^ x special case and the absorber special case, we
can no longer assume that one of the operands is RepOp, as we might
have a replacement higher up the instruction chain.

There is one optimization regression, but it is in a fuzzer-generated
test case.

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

CXXMethodDecl::isVirtual() count the number of overridden methods.
This assertion is not true before overridden methods are fully loaded.
The body of this CXXMethodDecl can introduce deps on a derived class
which contains a method overriding this method, causing the assertion failure.

ImportOverriddenMethods() is moved before body loading to fix this issue.

Testcase is contributed by Balázs Kéri (balazske)

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

Concepts aren't fully supporteb by hover yet. For the currently
supported case we add a test here to prevent regressions in the future.

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

Add it to lit.local.cfg so that it's actually run, and change it to
(properly) use the %clang_host substitution.

At the moment, the lowering from the Vector dialect to SME looks like
this:

  * Vector --> SME LLVM IR intrinsics

This patch introduces a new lowering layer between the Vector dialect
and the Arm SME extension:

  * Vector --> ArmSME dialect (custom Ops) --> SME LLVM IR intrinsics.

This is motivated by 2 considerations:
1. Storing `ZA` to memory (e.g. `vector.transfer_write`) requires an
   `scf.for` loop over all rows of `ZA`. Similar logic will apply to
   "load to ZA from memory". This is a rather complex transformation and
   a custom Op seems justified.
2. As discussed in [1], we need to prevent the LLVM type converter from
   having to convert types unsupported in LLVM, e.g.
   `vector<[16]x[16]xi8>`. A dedicated abstraction layer with custom Ops
   opens a path to some fine tuning (e.g. custom type converters) that
   will allow us to avoid this.

To facilitate this change, two new custom SME Op are introduced:

  * `TileStoreOp`, and
  * `ZeroOp`.

Note that no new functionality is added - these Ops merely model what's
already supported. In particular, the following tile size is assumed
(dimension and element size are fixed):

  * `vector<[16]x[16]xi8>`

The new lowering layer is introduced via a conversion pass between the
Vector and the SME dialects. You can use the `-convert-vector-to-sme`
flag to run it. The following function:
```
func.func @example(%arg0 : memref<?x?xi8>) {
  // (...)
  %cst = arith.constant dense<0> : vector<[16]x[16]xi8>
  vector.transfer_write %cst, %arg0 : vector<[16]x[16]xi8>, memref<?x?xi8>
  return
}
```
would be lowered to:
```
  func.func @example(%arg0: memref<?x?xi8>) {
    // (...)
    %0 = arm_sme.zero : vector<[16]x[16]xi8>
    arm_sme.tile_store %arg0[%c0, %c0], %0 : memref<?x?xi8>, vector<[16]x[16]xi8>
    return
  }
```

Later, a mechanism will be introduced to guarantee that `arm_sme.zero`
and `arm_sme.tile_store` operate on the same virtual tile. For `i8`
elements this is not required as there is only one tile.

In order to lower the above output to LLVM, use
  * `-convert-vector-to-llvm="enable-arm-sme"`.

[1] https://github.com/openxla/iree/issues/14294

Reviewed By: WanderAway

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