Reinstate use of FakeSection class to avoid constructing SectionChunk
from unintialised coff_section in FakeSectionChunk constructor.
Issue was caused by commit 5a58b19f9c93f3ac51bcde318508131ae78aa10c,
"[LLD] Remove global state in lld/COFF".
Merges `TransferOptions` into the newly-introduced
`DataflowAnalysisContext::Options` and removes explicit parameter for
`TransferOptions`, relying instead on the common options carried by the analysis
context. Given that there was no intent to allow different options between calls
to `transfer`, a common value for the options is preferable.
Differential Revision: https://reviews.llvm.org/D140703
There are a lot of variants of atomic operations, and AArch64 has several
distinct options to codegen them, and does different things depending on
available features, architecture version and optimisation level. The current
testing for atomic operations has been added gradually over time and does not
give full coverate. Given how complex the codegen for atomic operations is, it
is valuable to cover the entire parameter space, i.e. test them all. The
resulting set of tests serve also as a reference for how each is codegened.
In order to keep the test files readable and avoid constant updating for
unrelated codegen changes, the test outputs are filtered to only include the
relevant instructions. This shows for each operation and feature which codegen
approach is taken (e.g. ll/sc loop, atomic instruction, library call).
The following parameter space is tested:
- feature: +lse, +rcpc, etc
- optimisation level: O0, O1 (covers GISel and SelectionDAG)
- atomic instruction: load, store, cmpxchg, atomirmw*
- size: i8, i16, i32, i64, i128
- aligned/unaligned accesses
- endianness: big, little
- atomic ordering: release, acquire, etc
- load atomic only: const/non-const
- cmpxchg only: weak/strong
- atomicrmw: update operation (add, sub, etc)
Notably not covered:
- volatility: there should be no difference between volatile/non-volatile
- atomicrmw fadd/fsub
The files are split by triple, LLVM instruction, and feature. This makes it
easy to diff between features and endianness for a given instruction.
The file that generates the tests is included.
There are 70 test files with an average of 2800 lines each.
Differential Revision: https://reviews.llvm.org/D141064
Add a verifier to the TransformOpInterface ensuring that operations
implementing the interface define memory effects on their operands and
results.
Add the missing effects to TileToForeachThreadOp, specifically for
operands that were added at a later version of the op without modifying
`getEffects` accordingly.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D141371
Extract a static method to call the MLIR builders that translate LLVM IR
instructions to MLIR LLVM dialect operations. This change ensures the
MLIR builders have to use the moduleImport argument rather than calling
the import methods directly. As a result, both the intrinsic and the
instruction MLIR builders have to use a moduleImport argument and none
of them has direct access to private moduleImport methods. The revision
thus enforces consistent MLIR builder implementations for instructions
and intrinsics.
The revision also moves parseDataLayoutAlignment closer to its use.
Reviewed By: Dinistro
Differential Revision: https://reviews.llvm.org/D141265
As a result, we have identical alignment calculation of byval
parameters for:
- LowerCall() - getting alignment of an argument (.param)
- emitFunctionParamList() - getting alignment of a
parameter (.param) in a function declaration
- getPrototype() - getting alignment of a parameter (.param) in a
function prototypes that is used for indirect calls
This change is required to avoid ptxas error: 'Alignment of argument
does not match formal parameter'. This error happens even in cases
where it logically shouldn't.
For instance:
.param .align 4 .b8 param0[4];
...
callprototype ()_ (.param .align 2 .b8 _[4]);
...
Here we allocate 'param0' with alignment of 4 and it should be fine to
pass it to a function that requires minimum alignment of 2.
At least ptxas v12.0 rejects this code.
Differential Revision: https://reviews.llvm.org/D140581
Support of variadic functions triggers an assertion on several tests
from llvm/test/CodeGen/Generic/ if nvptx64-* is specified as a default
triplet:
Support for variadic functions (unsized array parameter) introduced in
PTX ISA version 6.0 and requires target sm_30.
That happens because those tests contain variadic function calls and
default versions of both PTX ISA (3.2) and architecture (sm_20) are
below the minimally required.
There were no observable problems with these tests before adding
support of variadic functions, because nvptx backend just didn't
handle them properly generating invalid PTX code.
Differential Revision: https://reviews.llvm.org/D141054
Keeping bitcasts in the common_bitcast() test, otherwise sinking
no longer occurs there. GVNSink seems to have a silly cost model
where sinking just the stores is considered non-profitable, but
sinking the stores and bitcasts (which are free...) is profitable.
As this is not a default-enabled pass, and this problem would exist
without opaque pointers as well, I'm not trying to do anything
about this.
As far as I can see they are unnecessary and in C++20 they lead to errors.
Removing them the tests pass with C++20 and the default version.
Example error message:
```
llvm-project/llvm/unittests/IR/PassBuilderCallbacksTest.cpp:275:30: error: expected unqualified-id before ‘)’ token
275 | MockAnalysisHandle<Module>() { setDefaults(); }
```
Differential Revision: https://reviews.llvm.org/D141358
The GreedyPatternRewriteDriver did previously not count the first iteration. I.e., when setting `config.maxIterations = 1`, two iterations were performed. In pratice, this number is not really important; we usually just need a limit in some reasonable order of magnitude. However, this fix allows us to write better convergence/worklist tests with carefully crafted test patterns to purposely trigger edge cases in the driver.
Similarly, the first rewrite was previously not counted towards `config.maxNumRewrites`.
For consistency, `OpPatternRewriteDriver` now uses `config.maxNumRewrites` instead of `config.maxIterations`; this driver does not have "iterations", it consists of a single loop (corresponding to the inner loop in the GreedyPatternRewriteDriver).
Differential Revision: https://reviews.llvm.org/D141365
Reapply with checks for instructions in unreachable blocks. A test
case for this was added in 1ee4a93b15bb.
-----
This is a recurring pattern: We want to find the nearest common
dominator (instruction) for two instructions, but currently only
provide an API for the nearest common dominator of two basic blocks.
Add an overload that accepts and return instructions.
This only effects folks building with wasm64 + shared memory which
is not currently a supported configuration in emscripten or any other
wasm toolchain.
Differential Revision: https://reviews.llvm.org/D141005
wasm32 was already supported, so here I've just reused the same regex. I'm not sure if this is actually correct: I don't know for certain if wasm32 and wasm64 have different output formats, but it seems to work.
Reviewed By: dschuff, asb
Differential Revision: https://reviews.llvm.org/D141130
This reverts commit 957952dbf2f34ed552e8e1f8c35eed17eee2ea38.
Addition in the newly added code can overflow. As a result, the
constructor of `BranchProbability()` can trigger an assertion. See
the discussion on https://reviews.llvm.org/D138132 for more details.
When the latch block is different from header block, IVInc will be expanded in the latch loop. We can't generate the post index load/store this case.
But if the IVInc only used in the loop, actually we still can use the post index load/store because when exit loop we don't care the last IVInc value.
So, trying to hoist IVInc to help backend to generate more post index load/store.
Fix#53625
Reviewed By: eopXD
Differential Revision: https://reviews.llvm.org/D138636
This commit adds function `vlenb` into riscv_vector.h. `vlenb` is defined
through builtin function `__builtin_rvv_vlenb`, which is lowered to
`llvm.read_register`.
Reviewed By: kito-cheng, pcwang-thead
Differential Revision: https://reviews.llvm.org/D141032
This test is testing whether the compiler behaves correctly when only
parts of an operand are masked.
In this case, no optimization is supposed to happen, since neither
the upper nor the lower half is
fully masked. Therefore, none
of the halves can be known to be zero.
The result is a regular multiplication.
This reverts commit a28f0747c2f3728bd8a6f64f7c8ba80b4e0cda9f.
It appears that this regresses some function definitions, added an
example as a comment over at https://reviews.llvm.org/D140956.
Tries to perform
(lshr (add (zext X), (zext Y)), K)
-> (icmp ult (add X, Y), X)
where
- The add's operands are zexts from a K-bits integer to a bigger type.
- The add is only used by the shr, or by iK (or narrower) truncates.
- The lshr type has more than 2 bits (other types are boolean math).
- K > 1
This seems to be a pattern that just comes from OpenCL front-ends, so adding DAG/GISel combines doesn't seem to be worth the complexity.
Original patch D107552 by @abinavpp - adapted to use (a + b < a) instead of uaddo following discussion on the review.
See this issue https://github.com/RadeonOpenCompute/ROCm/issues/488
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D138814
Move the code to lower an expression to address or a box in HLFIR from
Bridge.cpp to ConvertExpr.cpp so that it can be used inside
ConvertVariable.cpp (that needs to use a different symbol map that the
one held in the bridge).
Lower NULL to hlfir.null.
This allows lowering derived type constant structure constructors with
pointer components into fir.global.
Differential Revision: https://reviews.llvm.org/D141276
The current lowering of initial target in fir.global is relying
on how fir.box are created: instead of using a fir.rebox to add
the POINTER attribute to the created descriptor, it is looking
for a fir.embox defining operation and creating a copy of
it with a different result types.
The rational for doing so was that fir.rebox codegen was not possible
inside fir.global because it expects to manipulate the input fir.box
in memory, while objects cannot be manipulated in memory inside
a fir.global region that must be constant foldable.
But this approach has two problems:
- it won't work with hlfir where fir.box may be created by more
operations than fir.embox (e.g. hlfir.delcare or hlfir.designate).
In general, looking for a precise defining op for a value is
fragile.
- manually copying and modifying an operation is risky: it is easy
to forget copying some default operands (that could be added later).
This patch modifies the helpers to get descriptor fields so that they
can both operate on fir.box lowered in memory or in an llvm.struct
value. This enables the usage of fir.rebox in fir.global op.
The fallout in FIR tests is caused by the usage of constant index
when creating GEP (because extractOp requires constant indices).
MLIR builder uses i32 bit constant indices when non mlir::Value
indices are passed to the MLIR GEP op builder. Previously,
an 64 nist mlir constant value was created and passed to the GEP
builder. In this case, the builder respect the value type when
later generating the GEP.
Given this changes impact the "dimension" index that can, per
Fortran requirement, not be greated than 15, using a 32 bit index
is just fine and actually simplify the MLIR LLVM IR generation.
The fallout in lowering tests is caused by the introduction
of the fir.rebox everytime an initial target is created.
Differential Revision: https://reviews.llvm.org/D141136
This reverts commit 9f4a9d3f44501fa755eb71fe855e15cf0e59e8b8.
Reverting this change which was a follow-up to 5b72d0e4f5eeb8f90c744cac8e0728cffeca61a9 which is being reverted due to test failures on Mac/Windows.
Summary: This patch handles relocation field overflows in an XCOFF32 file. (XCOFF64 files may not have overflow section headers.) If a section has more than 65,534 relocation entries or line number entries, both of these fields are set to a value of 65535. In this case, an overflow section header with the s_flags field equal to STYP_OVRFLO is used to contain the relocation and line-number count information. Since line number is not supported, this patch only handles the relocation overflow.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D137819
When we see a store in generic mode we need to decide if we should guard
it for SPMDzation. This patch changes the getUnderlyingObjects call to
the more optimistic getAssumedUnderlyingObjects call to identify more
thread local pointers.
If LLVM_BUILTIN_TARGETS is not set, no OS specific variants will be
created, causing CMake build failure. Depend on the generic builtins
target if LLVM_BUILTIN_TARGETS is not set.
Differential Revision: https://reviews.llvm.org/D141273
