ms-stlye asm block is not supported on targets like arm/hexagon.
Specify a working target as POC.

Introduced by https://reviews.llvm.org/D154983

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

These two headers both contained a strange mix of definitions related to
both patterns and non-pattern transforms. Put patterns and "populate"
functions into Patterns.h and standalone transforms into Transforms.h.

Depends On: D155223

Reviewed By: nicolasvasilache

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

This is the first and most basic and important step for inlining memory operations with alias scopes.

For correctness, it is required that any alias scopes of inlined operations are replaced with deep copies. This is necessary as otherwise the same function could be inlined twice in one function, and suddenly the alias scopes extended.
A simple example would be `foo(a, b); foo(a2, b2)`. `a` and `a2` may alias. If `foo` is inlined in both instances, the store and load operations from `foo` may suddenly claim that `a` and `a2` do not alias if we were to keep the original alias scopes.

This is analogous to the following class/code in LLVM: https://github.com/llvm/llvm-project/blob/4eef2e30d6f89328a16d4f1d6b37f1c79afe850c/llvm/lib/Transforms/Utils/InlineFunction.cpp#L985

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

Snapshot all analysing files before running the tool, this makes sure
that we analyse all files statelessly and avoid the FileManager caching issue
when running `-edit` on multiple files.

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

Other compilers include the logical default also with the
default-integer-8 setting. This patch does the same for
flang.

Reviewed By: awarzynski, sscalpone

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

These should be lowered with genOptionalValue as in D154897, but I
haven't found any cases where this code path is actually hit (flang
tests, gfortran test suite), so I don't think it would be testable.
Adding an assertion for if this code path ever becomes live.

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

The previous code path created the elemental kernel by generating a
scalar intrinsic call using pre-prepared arguments using genIntrinsicRefCore,
which then generated the intrinsic call using genIntrinsicCall().

The problem with this approach was that the dynamically optional
arguments were marked as having no argLowering, which meant that they
were unconditionally passed by value without any check to see if they
were present.

It would be nice to put an if operation in the path for !argLowering,
doing something similar to genOptionalValue(). However, this can't be
done because it isn't clear what value should be used for the default.
If zero was used (like in genOptionalValue) this could effect the result
of MIN or MAX.

Instead, this patch re-uses the implementation for scalar dynamically
optional arguments (in non-elemental calls). This does the correct
thing, entirely ignoring absent optional arguments.

Depends On: D155292

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

Only minimal argument processing is needed here because they will be
lowered properly either by the elemental intrinsic call builder or the
lowering of the scalar call inside the elemental kernel.

Dynamically optional arrays are coming in the next patch.

Depends On: D155291

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

This should produce the same results as the FIR lowering

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

Bug #63699 shows a hang on arm in instcombine because we do not
propagate known bits for fshl/fshr rotates. We perform the propagation
and add regression test.

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

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