This reverts commit f6ddf778.

Eight buildbots reported that the two test files changed by that
commit had started failing. The buildbots in question all had in
common that they build with a very restricted `LLVM_TARGETS_TO_BUILD`,
such as only X86 or AArch64 or Hexagon. I didn't notice this before
commit because my own build has the full default set of targets, and
in that circumstance, the tests pass.

I assume the problem has something to do with the attempt to query
TargetTransformInfo: if you can't make a valid TTI for the target
triple then you can't ask it what kind of inline assembler you should
be emitting, and so `opt` without the Arm backend can't get the Arm
cases of these tests right.

I don't have time to fix this until next week, so I'll revert the
change for now to keep the buildbots happy.

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

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

The runtime type information table generator was broken when dealing
with an extension derived type that didn't include a special generic
procedure binding for ASSIGNMENT(=) or user-defined I/O, but one of
whose ancestor types did.  Ensure that the runtime derived type info
tables have complete subtables for all of these special bindings,
and respect any overrides that may have been defined.

Motivating example:
  type parent
   contains
    procedure :: dtWrite => dtWrite1
    generic :: write(formatted) => dtWrite
  end type
  type, extends(parent) :: extended
   contains
    procedure :: dtWrite => dtWrite2
  end type

The runtime derived type information table for "extended" must include
a special generic procedure entry for "write(formatted)" that points
to "dtWrite2" even though "extend" has no generic procedure for
"write(formatted)".

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

Currently when we synchronize the asynchronous queue for the plugins, we
ignore the return value. This is problematic because we will continue on
like nothing happened if the kernel fails.

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

Reviewed By: jdoerfert

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

This implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.

This change adds assembly support for all instructions except load-immediate instructions (fli.s/fli.d/fli.h).  Assembly support for that instruction and codegen support will follow in separate patches.

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

Convert test to use update_cc_test_checks.

This reverts commit 54c136e6. It was submitted without an appropriate patch description.  Will reapply shortly.

Revert "Update: [RISCV][MC] Add support for experimental zfa extension(FLI instruction not included)"

This reverts commit 321cd52b. It was submitted without an appropriate patch description.  Will reapply shortly.

Revert "[RISCV][CodeGen] Add codegen pattern for experimental zfa extension (FLI and FCVTMOD not included)"

This reverts commit fc6d517e.  It was submitted without an appropriate patch description.  Will reapply shortly.

NarrowSearchSpaceByPickingWinnerRegs has an aggressive filtering method to
reduce the complexity of the search space down by picking a best formula with
the highest number of reuses and assuming it will yield profitable reuse. In
certain cases we can find a best formula like {X+30,+,1} and later check a
formula like {X,+,1} with the same number of Uses. On some architectures it
can be better to pick {X,+,1}, especially if an offset of 30 can be used as a
legal addressing mode, but -30 cannot. That happens under Thumb1 code, which
has fairly limited addressing modes. This patch adds a check to see if it can
pick the simpler formula, if it looks more profitable.

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

The LowerTypeTests pass emits a jump table in the form of an
`inlineasm` IR node containing a string representation of some
assembly. It tests the target triple to see what architecture it
should be generating assembly for. But that's not good enough for
`Triple::thumb`, because the 32-bit PC-relative `b.w` branch
instruction isn't available in all supported architecture versions. In
particular, Armv6-M doesn't support that instruction (although the
similar Armv8-M Baseline does).

Most of this patch is concerned with working out whether the
compilation target is Armv6-M or not, which I'm doing by going through
all the functions in the module, retrieving a TargetTransformInfo for
each one, and querying it via a new method I've added to check its
SubtargetInfo. If any function's TTI indicates that it's targeting an
architecture supporting B.W, then we assume we're also allowed to use
B.W in the jump table.

The Armv6-M compatible jump table format requires a temporary
register, and therefore also has to use the stack in order to restore
that register.

Another consequence of this change is that jump tables on Arm/Thumb
are no longer always the same size. In particular, on an architecture
that supports Arm and Thumb-1 but not Thumb-2, the Arm and Thumb
tables are different sizes from //each other//. As a consequence,
``getJumpTableEntrySize`` can no longer base its answer on the target
triple's architecture: it has to take into account the decision that
``selectJumpTableArmEncoding`` made, which meant I had to move that
function to an earlier point in the code and store its answer in the
``LowerTypeTestsModule`` class.

Reviewed By: lenary

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

We can't test lowering calls with hlfir.expr arguments yet because this
hits a not yet implemented: "get shape form HLFIR expr without producer
holding the shape".

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

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

Add a HLFIR operation for the MATMUL transformational intrinsic,
according to the design set out in flang/doc/HighLevelFIR.md

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

`alwaysIncludeLeaves` was not respected by all code paths.

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

Instead of storing alignment for integers, floats, vectors and
structs in a single vector with a type tag, store them in
separate vectors instead. This makes the alignment lookup faster,
as we don't have to scan over irrelevant alignment entries.

Reviewed By: nicolasvasilache

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

This commit adds special handling for the debug intrinsic value
handling. LLVM allows to relax the def before use property for debug
intrinsics, so this property cannot be assumed for metadata values.

Reviewed By: gysit

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

Update ConstraintSystem to use a sparse representation for entries in a
row. Most rows only contain a small number of variables, so the sparse
representation can result in significant speedups.

For a large test case from D135915, it halves the time spent in
ConstraintElimination.

To ensure this returns the same results as the old implementation in all
cases, I built a large set of projects with an extra assertion that it
produces the same result as the old implementation.

This is the same routine generated in two different ways that ends up with
different orders to loads. The first currently does better than the second
with ordered loads, but needn't if the filtering in LSR is improved.

This patch adds the lowering strategy that lowers an array constructor
to an hlfir.elemental (without creating any temporary yet in lowering).
This will allow more high level array expression optimization to elide
the array constructor temporary when possible, but this is only doable
for a restricted although common form of array constructors:
"[(pure_scalar_expr(i),i=lower,upper,stride)]".

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

This is the first and biggest chunk that introduces support for
array constructor to HLFIR.

This patch:
- adds a new ConvertArrayConstructor.cpp that centralizes the
  code dealing with array constructor lowering.
- introduces a framework to lower array constructor according to
  different strategies: A common analysis of the array constructor is
  done, and based on that, a lowering startegy is selected and driven
  through the ac-values of the array constructor. See
  ConvertArrayConstructor.cpp comments for more details.
- implements the first strategy that creates a temporary inlined and
  updates it with inlined code. This strategy can only be used if the
  temporary can be pre-allocated (i.e: the extents and length parameters
  can be pre-computed without evaluating any ac-values), and if all the
  ac-value expressions are scalars.

For the sake of simplicity, characters and derived type will be enabled
once all the strategies are added.

Reviewed By: clementval, PeteSteinfeld

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

This patch adds parser suppert for the device_type clause used by the Declare Target directive.

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

When the rhs is polymorphic and allocated during assignment, the
derivedType might have change from the one set in `toDerived`.
Use the one set in the addendum so it is always up to date.

This can happen in cases like the one shown below:

```
type :: t1
end type t1

type, extends(t1) :: t2
  integer, allocatable :: i(:)
end type

subroutine assign(t)
  class(t2), intent(in) :: t
  class(t1), allocatable :: cp

  cp = t
end subroutine
```

Reviewed By: jeanPerier

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

A new transform dialect op is introduced to perform the rewrite.
The test pass option is now obsolete and is removed in favor of the transform.

In the process I realized the tensor.pad nofold attribute was not taken into account
and added support to emit a bufferization.alloc_tensor + linalg.copy.

Reviewed By: springerm

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

This is permitted by the op, but the current lowering generates invalid IR.

Reviewed By: springerm

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

Adds intrinsics for the following SME2 instructions:
 - smlall (1, 2 & 4 vectors)
 - umlall (1, 2 & 4 vectors)
 - smlsll (1, 2 & 4 vectors)
 - umlsll (1, 2 & 4 vectors)
 - sumlall (2 & 4 vectors)
 - usmlall (1, 2 & 4 vectors)

NOTE: These intrinsics are still in development and are subject to future changes.

Reviewed By: david-arm

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

Current code are crashing on the assert `assert(seqTy && "must be an array");`.

Add a TODO instead until the support is in.

Reviewed By: jeanPerier

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

The `basic_string_view` constructor accepting a contiguous range rejects
converting between `basic_string_view` even when only the trait types vary.
This prevents conversions for converting from `basic_string_view<C, T1>` and
`basic_string<C, T1, A>` to `basic_string_view<C, T2>`.  Recently, this
constructor was made `explicit`, so there's no reason to really forbid this
conversion anymore.

Relax the restriction that the trait types need to match in this constructor.

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

Reviewed By: cor3ntin

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

We are about to allow different trace strategies for MachineCombiner. Make
the name of the ensemble strategy-neutral.

Depends on D140540

Reviewed By: spatel

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