This fixes a crash when lowering an extract_subvector like:

t0:v1i64 = extract_subvector t1:v2i64, 1

Whilst we never need a vslidedown with M1 on scalable vector types, we might
need to do it for v1i64/v1f64, since the smallest container type for it is
nxv1i64/nxv1f64.

The lowering code is still correct for this case, but the assertion was too
strict. The actual invariant we're relying on is that ContainerSubVecVT's LMUL
<= M1, not < M1. Hence why we handled v2i32 fine, because its container type
was nxv1i32 and MF2.

Common backends (LLVM, SPIR-V) only supports 1D vectors, LLVM conversion
handles ND vectors (N >= 2) as `array<array<... vector>>` and SPIR-V
conversion doesn't handle them at all at the moment. Sometimes it's
preferable to treat multidim vectors as linearized 1D. Add pass to do
this. Only constants and simple elementwise ops are supported for now.

@krzysz00 I've extracted yours result type conversion code from
LegalizeToF32 and moved it to common place.

Also, add ConversionPattern class operating on traits.

Adds a test to help document Linalg Ops that are currently not supported
by the vectoriser (i.e. the logic to vectorise these is missing). The
list is not exhaustive.

Fix crash raised in comments for 5c9f7682

This patch adds support for the depend clause in a number of OpenMP
directives/constructs related to offloading. Specifically, it adds the
handling of the depend clause when it is used with the following
constructs

- target
- target enter data
- target update data
- target exit data

Without this I would hit errors with libstdc++-12 like:

/usr/include/c++/12/bits/stl_iterator_base_funcs.h:230:5: note:
candidate template ignored: substitution failure [with _InputIterator =
llvm::const_set_bits_iterator_impl<llvm::BitVector>]: argument may not
have 'void' type
    next(_InputIterator __x, typename
    ^

The 1-D case directly maps to LLVM intrinsics. The n-D case will be
handled by unrolling to 1-D first (in a later patch).

Depends on: #80965

Although in a normal implementation the assumption is reasonable, it
seems that some esoteric implementation are not returning a T&. This
should be handled correctly and the values be propagated.

---------

Co-authored-by: martinboehme <mboehme@google.com>

The motivation here was a suggestion over in Compiler Explorer. You can
use `-mllvm` already to do this but since gfortran supports `-masm`, I
figured I'd try to add it.

This is done by flang expanding `-masm` into `-mllvm x86-asm-syntax=`,
then passing that to fc1. Which then collects all the `-mllvm` options
and forwards them on.

The code to expand it comes from clang `Clang::AddX86TargetArgs` (there
are some other places doing the same thing too). However I've removed
the `-inline-asm` that clang adds, as fortran doesn't have inline
assembly.

So `-masm` for flang purely changes the style of assembly output.

```
$ ./bin/flang-new /tmp/test.f90 -o - -S -target x86_64-linux-gnu
<...>
        pushq   %rbp
$ ./bin/flang-new /tmp/test.f90 -o - -S -target x86_64-linux-gnu -masm=att
<...>
        pushq   %rbp
$ ./bin/flang-new /tmp/test.f90 -o - -S -target x86_64-linux-gnu -masm=intel
<...>
        push    rbp
```

The test is adapted from `clang/test/Driver/masm.c` by removing the
clang-cl related lines and changing the 32 bit triples to 64 bit triples
since flang doesn't support 32 bit targets.

This patch adds full support for linking SystemZ (ELF s390x) object
files. Support should be generally complete:
- All relocation types are supported.
- Full shared library support (DYNAMIC, GOT, PLT, ifunc).
- Relaxation of TLS and GOT relocations where appropriate.
- Platform-specific test cases.

In addition to new platform code and the obvious changes, there were a
few additional changes to common code:

- Add three new RelExpr members (R_GOTPLT_OFF, R_GOTPLT_PC, and
R_PLT_GOTREL) needed to support certain s390x relocations. I chose not
to use a platform-specific name since nothing in the definition of these
relocs is actually platform-specific; it is well possible that other
platforms will need the same.

- A couple of tweaks to TLS relocation handling, as the particular
semantics of the s390x versions differ slightly. See comments in the
code.

This was tested by building and testing >1500 Fedora packages, with only
a handful...

Use templates instead.

Part of <https://github.com/llvm/llvm-project/issues/62629>.

[clang-tidy] ignore local variable with [maybe_unused] attribute in bugprone-unused-local-non-trivial-variable (#81563)

This reverts commit a034e65e.

Some protobuf users reported that this patch caused a significant
compile-time regression because `TailDuplicator` works poorly with a
specific pattern.

We will reland it once the codegen issue is fixed.

The strictfp attribute has the requirement that "LLVM will not introduce
any new floating-point instructions that may trap". The llvm.is.fpclass
intrinsic is documented as "The function never raises floating-point
exceptions", and the fcmp instruction may raise one, so we can't
transform the former into the latter in functions with the strictfp
attribute.

llvm.dbg.assign intrinsics have 2 {value, expression} pairs; fix hwasan to
update the second expression.

Fixes #76545. This is #78606 rebased and with the addition of DPValue handling.
Note the addition of --try-experimental-debuginfo-iterators in the tests and
some shuffling of code in MemoryTaggingSupport.cpp.

This function will be useful when we change the behavior of record-type
prvalues
so that they directly initialize the associated result object. See also
the
comment here for more details:


https://github.com/llvm/llvm-project/blob/9e73656af524a2c592978aec91de67316c5ce69f/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h#L354

As part of this patch, we document and assert that synthetic fields may
not have
reference type.

There is no practical use case for this: A `StorageLocation` may not
have
reference type, and a synthetic field of the corresponding non-reference
type
can serve the same purpose.

Currently, `phaseParity` argument of `nvgpu.mbarrier.try_wait.parity` is
index. This can cause a problem if it's passed any value different than
0 or 1. Because the PTX instruction only accepts even or odd phase. This
PR makes phaseParity argument i1 to avoid misuse.

Here is the information from PTX doc:

```
The .parity variant of the instructions test for the completion of the phase indicated 
by the operand phaseParity, which is the integer parity of either the current phase or 
the immediately preceding phase of the mbarrier object. An even phase has integer 
parity 0 and an odd phase has integer parity of 1. So the valid values of phaseParity 
operand are 0 and 1.
```
See for more information:

https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#parallel-synchronization-and-communication-instructions-mbarrier-test-wait-mbarrier-try-wait

They can be also used in `clang`.
Introduce the lightweight header instead of `CoverageMapping.h`.

This includes for now:
* `mcdc::ConditionID`
* `mcdc::Parameters`

This is one option for attempting to move genMinMaxlocReductionLoop to a
better location. It moves it into Transforms and makes HLFIRTranforms
depend upon FIRTransforms.

It passes a build locally, both with and without -DBUILD_SHARED_LIBS,
and does OK on the windows CI.

If we have something like G_TRUNC from v2s32 to v2s16, then lowering
this to a concat of two G_TRUNC s32 to s16 followed by G_TRUNC from
v2s16 to v2s8 does not bring us any closer to legality. In fact, the
first part of that is a G_BUILD_VECTOR whose legalization will produce a
new G_TRUNC from v2s32 to v2s16, and both G_TRUNCs will then get
combined to the original, causing a legalization cycle.

Make the lowering condition more precise, by requiring that the original
vector is >128 bits, which is I believe the only case where this
specific splitting approach is useful.

Note that this doesn't actually produce a legal result (the alwaysLegal
is a lie, as before), but it will cause a proper globalisel abort
instead of an infinite legalization loop.

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

Fix discrepancy from when this was forked from the SkylakeServer model

This also fixes VRANGEPS/VRANGEPD instructions which typically match FADD characteristics

Confirmed with Agner + uops.info

Fixes #81504

This patch covers CWG issues
[201](https://cplusplus.github.io/CWG/issues/201.html),
[210](https://cplusplus.github.io/CWG/issues/210.html),
[292](https://cplusplus.github.io/CWG/issues/292.html).

[CWG208](https://cplusplus.github.io/CWG/issues/208.html) is not
covered, as it actually requires a libcxxabi test.

Resolution of CWG292 has been superseded by
[P0145R3](https://wg21.link/p0145r3) "Refining Expression Evaluation
Order for Idiomatic C++"
(see changes to paragraph 5.3.4/18).

Allow TMA's last dimension to be non-128B when swizzling mode is not
set.

Test `tma_load_64x8_8x128_noswizzle.mlir` is failing due to the
verifier. This PR will fix that

Fixes SWDEV-443292

Asserts that the shift amount is in range and update ExpandShiftByConstant to use getShiftAmountConstant (and legal shift amount types).

The standard declares the copy constructors and copy assign operators as
deleted.

References:
- https://eel.is/c++draft/string.streams

This special case is wrong, we need to handle pointer types here
just like anything else.

These were implemented in the COFF linker in
3923e61b and
d12b99a4.

This matches the corresponding options in the ELF linker.

This PR moves lowering of math dialect later in the pipeline. Because
math dialect is lowered correctly by createConvertGpuOpsToNVVMOps for
GPU target, and it needs to run it first.

Reland #78556

[AMDGPU][GlobalIsel] Introduce isRegisterClassType to check for legal types, instead of checking bit width.  (#68189)

In D151116 it was suggested to have a set of classes to cover every
possible case. This does it for bitcast first.

closes #79578