i16/f16/bf16 will use the same .b16 registers and
i32/v2f16 and v2bf16 will share .b32 registers.

The changes are mostly mechanical, intended to remove unnecessary register
classes which tend to produce redundant register moves.

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

v2f16 regtype conversion to i32

Reviewed By: erichkeane, nickdesaulniers

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

db7cc034 added OpenMP support to the execution engine but didn't
add the explicit CMake dependency.

We've observed that the MLIR Jit Engine fails when the `omp` dialect is used due to a failure to register OpenMP-related translations. This small patch addresses this issue.

Reviewed By: mehdi_amini

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

Trusty runs in memory constrained environments, with many apps
having only one page (4KB) of heap memory available. However, we
still want to mmap() multiples of PAGE_SIZE at a time.

Additionally, switch Scudo from using sbrk() to mmap().

Reviewed By: cferris

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

Addresses the issue found by:
https://lab.llvm.org/buildbot/#/builders/30/builds/35886

Contribute a grammar, along with associated tests, from the upstream
project maintained at https://github.com/artagnon/tree-sitter-mlir. The
new grammar includes several fixes, and successfully parses 60-80% of
MLIR tests in the Arith, Math, ControlFlow, SCF, Tensor, Affine, and
Linalg dialects.

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

This commit fixes "TextDiagnostic::emitIncludeLocation" when compiling
with "-fdiagnostics-absolute-paths" flag enabled by emitting the absolute
path of the included file.

Fixes #63026

Reviewed By: aaron.ballman

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

Since all the type traits up until now have had Boolean vaules, we've
always been able to assume that the expressions are `bool`. This is
about to change (D151952 introduces a trait that returns `size_t`), so
we need to restructure the code so it doesn't become unwieldy.

This is achieved by giving traits a designated "return" type.

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

Map `ieee_fma` intrinsic to LLVM IR as `llvm.fma`.

Reviewed By: klausler

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

Three new transforms:
    1) `(icmp pred (shl nsw nuw X, Y), C)` [if `C <= 0`] -> `(icmp pred X, C)`
        - ugt: https://alive2.llvm.org/ce/z/K_57J_
        - sgt: https://alive2.llvm.org/ce/z/BL8u_a
        - sge: https://alive2.llvm.org/ce/z/yZZVYz
        - uge: https://alive2.llvm.org/ce/z/R4jwwJ
        - ule: https://alive2.llvm.org/ce/z/-gbmth
        - sle: https://alive2.llvm.org/ce/z/ycZVsh
        - slt: https://alive2.llvm.org/ce/z/4MzHYm
        - sle: https://alive2.llvm.org/ce/z/fgNfex
        - ult: https://alive2.llvm.org/ce/z/cXfvH5
        - eq : https://alive2.llvm.org/ce/z/sZh_Ti
        - ne : https://alive2.llvm.org/ce/z/UrqSWA

    2) `(icmp eq/ne (shl {nsw|nuw} X, Y), 0)` -> `(icmp eq/ne X, 0)`
        - eq+nsw: https://alive2.llvm.org/ce/z/aSJN6D
        - eq+nuw: https://alive2.llvm.org/ce/z/r2_-br
        - ne+nuw: https://alive2.llvm.org/ce/z/RkETtu
        - ne+nsw: https://alive2.llvm.org/ce/z/8iSfW3

    3) `(icmp slt (shl nsw X, Y), 0/1)` -> `(icmp pred X, 0/1)`
       `(icmp sgt (shl nsw X, Y), 0/-1)` -> `(icmp pred X, 0/-1)`
        - slt: https://alive2.llvm.org/ce/z/eZYRan
        - sgt: https://alive2.llvm.org/ce/z/QQeP26

    Transform 3) is really sle/slt/sge/sgt with 0, but sle/sge
    canonicalize to slt/sgt respectively so its implemented as such.

Reviewed By: nikic

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

Reviewed By: nikic

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

Reviewed By: aartbik

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

A variable declared with __attribute__((cleanup)) cannot be unused, as
its address is passed to the clean up function. Do not emit
-Wunused-variable for variables declared with the cleanup attribute,
which matches GCC's behavior: https://godbolt.org/z/dz5YfTsan

Reviewed By: erichkeane, nickdesaulniers

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

Simplify D99750 by factoring out a utility which we already have multiple instances of in tree.

Several OCaml modules using the old PassManager API were removed in
https://reviews.llvm.org/D144751, but the META file still needed to be
updated to remove them. This diff also removes an unused macro definition
related to the module removals.

Reviewed By: nikic

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

This reverts commit 6a2e0cb4.

Define the function @llvm.amdgcn.make.buffer.rsrc, which take a 64-bit
pointer, the 16-bit stride/swizzling constant that replace the high 16
bits of an address in a buffer resource, the 32-bit extent/number of
elements, and the 32-bit flags (the latter two being the 3rd and 4th
wards of the resource), and combines them into a ptr addrspace(8).

This intrinsic is lowered during the early phases of the backend.

This intrinsic is needed so that alias analysis can correctly infer
that a certain buffer resource points to the same memory as some
global pointer. Previous methods of constructing buffer resources,
which relied on ptrtoint, would not allow for such an inference.

Depends on D148184

Reviewed By: arsenm

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

1. Remove the existing code that would encode the constant offsets (if
there were any) on buffer intrinsic operations onto their
`MachineMemOperand`s. As far as I can tell, this use of `offset` has
no substantial impact on the generated code, especially since the same
reasoning is performed by areMemAccessesTriviallyDisjoint().

2. When a buffer resource intrinsic takes a pointer argument as the
base resource/descriptor, place that memory argument in the value
field of the MachineMemOperand attached to that intrinsic.

This is more conservative than what would be produced by more typical
LLVM code using GEP, as the Value (for alias analysis purposes)
corresponding to accessing buffer[0] and buffer[1] is the same.
However, the target-specific analysis of disjoint offsets covers a lot
of the simple usecases.

Despite this limitation, the new buffer intrinsics, combined with
LLVM's existing pointer annotations, allow for non-trivial
optimizations, as seen in the new tests, where marking two buffer
descriptors "noalias" allows merging together loads and stores in a
"load from A, modify loaded value, store to B" sequence, which would
not be possible previously.

Depends on D147547

Reviewed By: arsenm

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

This reverts commit b1dc43aa.

In order to enable the LLVM frontend to better analyze buffer
operations (and to potentially enable more precise analyses on the
backend), define versions of the raw and structured buffer intrinsics
that use `ptr addrspace(8)` instead of `<4 x i32>` to represent their
rsrc arguments.

The new intrinsics are named by replacing `buffer.` with `buffer.ptr`.

One advantage to these intrinsic definitions is that, instead of
specifying that a buffer load/store will read/write some memory, we
can indicate that the memory read or written will be based on the
pointer argument. This means that, for example, a read from a
`noalias` buffer can be pulled out of a loop that is modifying a
distinct buffer.

In the future, we will define custom PseudoSourceValues that will
allow us to package up the (buffer, index, offset) triples that buffer
intrinsics contain and allow for more precise backend analysis.

This work also enables creating address space 7, whic...

This was originally a part of D149104 which was backed out. This change
is uncontroversial though, so split it out and reland it.

Reviewed By: MaskRay

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

Unstructured regions presents some issues for OpenMP code generation.
While there are no branches out of the OpenMP region, there can be
branches inside. This required the availability of an artificial
target at the end of an OpenMP region. This was implemented by
insertion an artifical `continue` and marking it as a target for
a branch.
(https://github.com/flang-compiler/f18-llvm-project/pull/1178)

The artificial target is not required for OpenMP loops. Since the
DO loop end can itself be a target of a branch. Moreover, insertion
of the continue between the end of the loop and the end of the
OpenMP loop construct presents problems since the OpenMP MLIR
loop construct models both the loop and the construct. This can
cause the terminator of the OpenMP loop construct to be missed.
This patch solves the issue by skipping the insertion of the
continue.

Note: This issue is only hit if the `end openmp loop` directive
is missed.

This patch fixes the issues...

This allows us to remove the uimm5 argument and changes the
scheduler class from ALU to Shift.

Ultimately we need a WShift scheduler class, but we need to scrub
all of the crypto instructions for scheduler classes so I'll leave
that for future work.

Reviewed By: 4vtomat, ego

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

As per section 4.2.2 of the PowerPC ELFv2 ABI, this value tells the dynamic linker which optimizations it is allowed to do.
Specifically, the higher order bit of the two tells the dynamic linker that there may be multiple TOC pointers in the binary.

When we resolve any NOTOC relocations during linking, we need to set this value because we may be calling
TOC functions from NOTOC functions when the NOTOC function already clobbered the TOC pointer.

In practice, this ensures that the PLT resolver always resolves the call to the GEP (global entry point) of
the TOC function (which will set up the TOC for the TOC function).

Original patch by nemanjai

Reviewed By: MaskRay

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

(When clients support it, otherwise keep the existing rendering).

In VSCode this makes the signature darker.

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

The OpenMP loop Operations have the bounds attached to them. If the
loop bounds are privatised then the privatisation has to happen
before the loop operation is created. To do this the privatisation
is split into two steps. The first step performs cloning and
firstprivate handling, the second step performs lastprivate handling.

This also reverts the changes in the temporary fix (D127137).

Fixes https://github.com/flang-compiler/f18-llvm-project/issues/1171#issuecomment-1143880545
Fixes https://github.com/flang-compiler/f18-llvm-project/issues/1171#issuecomment-1119997442

Fixes #60872

Reviewed By: NimishMishra

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

Examle:
```
struct test {
	char a;
	char b : 3;
	char c : 5;
	int d;
	int e : 27;
};
```

{F27617774}
{F27617776}
{F27617777}
{F27617780}

Reviewed By: sammccall

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

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

Reviewed By: #libunwind, mstorsjo

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

Amends 12728e14
Addresses issues found by:
https://lab.llvm.org/buildbot/#/builders/216/builds/22308

Amends 12728e14
Found by:
https://lab.llvm.org/buildbot/#/builders/139/builds/42135

Test for the issue reported at https://reviews.llvm.org/D149331#4387931.

This reverts commit 5cbb9f7a.

Causes verifier error reported at
https://reviews.llvm.org/D149331#4387931.

This patch updates the docs for fuse_into_containing_op. It
updates the returned values to include the new_containing_op
and adds a brief description of the new_containing_op.

updates the docs with new changes in the
op regarding the return of the new_containing_op as well
as a brief description o

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