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

This patch uses castAs instead of getAs which will assert if the type doesn't match in checkSizelessVectorShift(clang::Sema &, clang::ActionResult<clang::Expr *, true> &, clang::ActionResult<clang::Expr *, true> &, clang::SourceLocation, bool).

Reviewed By: erichkeane

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

_Generic accepts an expression operand whose type is matched against a
list of associations. The expression operand is unevaluated, but the
type matched is the type after lvalue conversion. This conversion loses
type information, which makes it more difficult to match against
qualified or incomplete types.

This extension allows _Generic to accept a type operand instead of an
expression operand. The type operand form does not undergo any
conversions and is matched directly against the association list.

This extension is also supported in C++ as we already supported
_Generic selection expressions there.

The RFC for this extension can be found at:
https://discourse.llvm.org/t/rfc-generic-selection-expression-with-a-type-operand/70388

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

This reverts commit e69fa03d.

This patch lead to build time outs on the AMDGPU OpenMP runtime
buildbot.

Handling `true` and `false` constant replacements is now abstracted
out into a single lambda function `ReplaceCmpWithConstant`, so as to
reduce code duplication.

Integer constants with bit width less than a word (e.g., i8, i16)
should be bit extended based on its type to be SPIR-V spec-compliant.
Previously, the decision was based on the most significant bit of the
value which ignores the signless semantics and causes problems when
interfacing with SPIR-V tools.

Dealing with numeric literals: the SPIR-V spec says, "If a numeric
type’s bit width is less than 32-bits, the value appears in the
low-order bits of the word, and the high-order bits must be 0 for
a floating-point type or integer type with Signedness of 0, or sign
extended for an integer type with a Signedness of 1 (similarly for the
remaining bits of widths larger than 32 bits but not a multiple of 32
bits)."

Therefore, signless integers (e.g., i8, i16) and unsigned integers
should be 0-extended, and signed integers (e.g., si8, si16) should be
sign-extended.

Patch By: mshahneo
Reviewed By: kuhar

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

This reverts commit 5362a0d8.

In preparation for reverting a dependent revision.

This finishes the transition of tests covered in generate_header_tests.py
to the new .gen.py format.

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

Implement stop_token
http://eel.is/c++draft/thread.stoptoken

This is only needed in C.

Depends on D151989

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

In the vector distribute patterns, we used to move
`vector.transfer_read`s out of `vector.warp_execute_on_lane0`s
irrespectively of how they were defined.

This could create transfer_read operations that would read values from
within the warpOp's body from outside of the body.
E.g.,
```
warpop {
  %defined_in_body
  %read = transfer_read %defined_in_body
  vector.yield %read
}
```
=>
```
warpop {
  %defined_in_body
  vector.yield ...
}
// %defined_in_body is referenced outside of its scope.
%read = transfer_read %defined_in_body
```

The fix consists in checking that all the values feeding the new
`transfer_read` are defined outside of warpOp's body.

Note: We could do this check before creating any operation, but that would
mean knowing what `affine::makeComposedAffineApply` actually do. So the
current fix is a trade off of coupling the implementations of this
propagation and `makeComposedAffineApply` versus compile time.

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

This removes BitCasts from isSource in Type Promotion, as I don't believe they
need to be treated as Sources. They will usually be from floats or hoisted
constants, where constants will be handled already.

This fixes #62513, but didn't otherwise cause any differences in the tests I
ran.

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