This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Currently, the import of LLVMIR fails if the program contains debug
intrinsics. The revision adds support to import debug intrinsics that
have no debug expression attached and drops all debug intrinsics with a
non-empty debug expression. It also moves the existing debug intrinsics
into the "intr" namespace by deriving from LLVM_IntrOp.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D138405
Instead of importing constant expressions recursively, the revision
walks all dependencies of an LLVM constant iteratively. The actual
conversion then iterates over a list of constants and all intermediate
constant values are added to the value mapping. As a result, an LLVM IR
constant maps to exactly one MLIR operation per function. The revision
adapts the existing tests since the constant ordering changed for
aggregate types. Additionally, it adds extra tests that mix aggregate
constants and constant expressions.
Depends on D137416
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D137559
Add a DebugImporter to convert LLVMIR debug metadata into
MLIR debug attributes. It is the counterpart to the
DebugTranslation class and supports the same attributes.
The revision only supports the translation of instruction,
function, and module debug information. The import of
intrinsics is left to a later revision.
Depends on D138206
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D138209
The revision makes specific debug information attribute parameters
optional since some of them can be omitted in LLVMIR. The additional
flexibility enables a later revision that will support importing
debug information from LLVMIR. A special case is the types parameter
of the SubroutineTypeAttr. For void functions, its first entry is
null in LLVMIR. This revision splits the type parameter in an optional
resultType parameter and an argumentTypes array to support this corner
case.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D138206
Update the SPIRV `mlir-translate` translations to translate to/from
`spirv.module` instead of `builtin.module`. This simplifies the
translation since the code no longer needs to walk the module looking
for a SPIRV module, however it requires passing `-no-implicit-module` to
all the tests.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D135819
Insert constants and globals in order by maintaining the position
of the constant and global inserted last. Update the tests
to reflect the updated insertion order. Also make sure functions
are always inserted at the end of the module instead of at
the second last position and delete a spurious function in
the intrinsic.ll that seems to exist to avoid the first
function under test ends up at the end of the module.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D136679
So far the function argument attributes were only translated
for functions with bodies. This change makes sure that this
happens for functions without bodies (declarations) as well.
This is needed for https://github.com/llvm/llvm-project/issues/58579
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D137047
The call_intrinsic op allows us to call LLVM intrinsics from the LLVMDialect without implementing a new op every time.
Reviewed By: lattner, rriddle
Differential Revision: https://reviews.llvm.org/D137187
PTX programming models provides some performance tuning directives; see https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#performance-tuning-directives
The downstream compiler namely `ptxas` leverages these information for better register allocation or to handle other resource management that improves the performance.
This revision introduce all the kernel based directives to MLIR's NVVM dialect. The list is below
```
maxnreg -> max register per thread in CTA
maxntid -> max threads per CTA
reqntid -> exact number of threads per CTA
minnctapersm -> min CTA per SM
```
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D136931
This diff adds initial (partial) support for "fastmath" attributes for floating
point operations in the arithmetic dialect. The "fastmath" attributes are
implemented using a default-valued bit enum. The defined flags currently mirror
the fastmath flags in the LLVM dialect (and in LLVM itself). Extending the
set of flags (if necessary) is left as a future task.
In this diff:
- Definition of FastMathAttr as a custom attribute in the Arithmetic dialect
that inherits from the EnumAttr class.
- Definition of ArithFastMathInterface, which is an interface that is
implemented by operations that have an arith::fastmath attribute.
- Declaration of a default-valued fastmath attribute for unary and (some) binary
floating point operations in the Arithmetic dialect.
- Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags
NOT in this diff (but planned or currently in progress):
- Documentation of flag meanings
- Addition of FastMathAttr attributes to other dialects that might lower to the
Arithmetic dialect (e.g. Math and Complex)
- Folding/rewrite implementations that are enabled by fastmath flags
- Specification of fastmath values from Python bindings (pending other in-
progress diffs)
Reviewed By: mehdi_amini, vzakhari
Differential Revision: https://reviews.llvm.org/D126305
This has been a long standing TODO, and actually enables users to generate
debug information for LLVM using the LLVM dialect; as opposed to our
dummy placeholder that generated just enough for line table information.
Differential Revision: https://reviews.llvm.org/D136543
This adds a '--no-implicit-module' option, which disables the insertion
of a top-level 'builtin.module' during parsing.
The translation APIs are also updated to take/return 'Operation*'
instead of 'ModuleOp', to allow other operation types to be used. To
simplify translations which are restricted to specific operation types,
'TranslateFromMLIRRegistration' has an overload which performs the
necessary cast and error checking.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D134237
Rename single letter member variables and function arguments to use
longer names in ConvertFromLLVMIR.cpp. Also drop some uses of auto in
favor our spelling out the type and refactor some llvm::enumerate loops.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D136246
The revision performs a topological sort of the blocks to
ensure the operations are processed in dominance order.
After the change, we do not need to introduce dummy
instructions if an operand has not yet been processed.
Additionally, the revision also moves and simplifies the
control-flow related tests to a separate test file.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D136230
Currently generation of align assumptions for OpenMP simd construct is done
outside OMPIRBuilder for C code and it is not supported for Fortran.
According to OpenMP 5.0 standard (2.9.3) only pointers and arrays can be
aligned for C code.
If given aligned variable is pointer, then Clang generates the following set
of the LLVM IR isntructions to support simd align clause:
; memory allocation for pointer address:
%A.addr = alloca ptr, align 8
; some LLVM IR code
; Alignment instructions (alignment is equal to 32):
%0 = load ptr, ptr %A.addr, align 8
call void @llvm.assume(i1 true) [ "align"(ptr %0, i64 32) ]
If given aligned variable is array, then Clang generates the following set
of the LLVM IR isntructions to support simd align clause:
; memory allocation for array:
%B = alloca [10 x i32], align 16
; some LLVM IR code
; Alignment instructions (alignment is equal to 32):
%arraydecay = getelementptr inbounds [10 x i32], ptr %B, i64 0, i64 0
call void @llvm.assume(i1 true) [ "align"(ptr %arraydecay, i64 32) ]
OMPIRBuilder was modified to generate aligned assumptions. It generates only
llvm.assume calls. Frontend is responsible for generation of aligned pointer
and getting the default alignment value if user does not specify it in aligned
clause.
Unit and regression tests were added to check if aligned clause was handled correctly.
Differential Revision: https://reviews.llvm.org/D133578
Reviewed By: jdoerfert
The revision adds support for importing the masked load/store and
gather/scatter intrinsics from LLVM IR. To enable the import, the
revision also includes an extension of the mlirBuilder code generation
to support variadic arguments.
Depends on D136057
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D136058
This allows for setting an attribute using the underlying C++ type,
which is generally much nicer to interact with than the attribute type.
Differential Revision: https://reviews.llvm.org/D135838
The revision imports the atomic operations using
tablegen generated builders. Additionally, it moves their tests to
the instructions.ll test file.
Depends on D135880
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135944
The revision imports the shuffle vector operation using
tablegen generated builders. Additionally, it moves its test to
the instructions.ll test file.
Depends on D135874
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135880
The revision imports the extract and insert value operations using
tablegen generated builders. Additionally, it moves the tests to
the instructions.ll test file.
Reviewed By: ftynse, dcaballe
Differential Revision: https://reviews.llvm.org/D135874
The revision imports compare operations using TableGen generated
builders, instead of using the special handlers defined by the Importer.
It therefore adds a new llvmArgIndexes field that allows to specify
a mapping between MLIR argument and LLVM IR operand indexes if they do
not match. Additionally, the FCmp op is extended with an additional
builder and all compare operations are extended with verification
traits to ensure the operands types match. These extensions simplify
the logic of the newly introduced builders and are in line with the
compare operations define by the arithmetic dialect.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135855
The revision uses tablegen generated builders to convert the most common
LLVM IR instructions to MLIR LLVM dialect operations. All instructions
with special handlers, except for alloca and fence, still use manual
handlers. The revision also introduces an additional "instructions.ll"
test file to test the import of instructions that have tablegen builders
(except for the resume instruction whose test remains untouched). A part
of the test cases are new, for example the integer instruction test,
while others are migrated from the "basic.ll" test file.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135709
The revision adds a mapValue function to the Importer, which can be used
in the MLIR builders to provide controlled accesses to the result
mapping of the imported instructions. Additionally, the change allows us
to avoid accessing a private member variable of the Importer class,
which simplifies future refactorings that aim at factoring out a
conversion interface (similar to the MLIR to LLVM translation). The
revision also renames the variables used when emitting the MLIR builders
to prepare the generalization to non-intrinsic instructions. In
particular, it renames callInst to inst and it passes in the instruction
arguments using an llvmOperands array rather than accessing the call
arguments directly.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135645
The revision adds support to specify custom import functions for
LLVM IR intrinsics with immediate arguments that translate to MLIR
attributes. It takes an approach similar to the MLIR to LLVM translation
that uses a tablegen defined build method. The default implementation
of this newly introduced "mlirBuilder" assumes all intrinsic arguments
translate to operands. Specific intrinsics, such as
llvm.lifetime.start/stop then define a custom builder that converts
their immediate arguments to MLIR attributes.
Depends on D135349
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135350
The revision renames some methods of the Importer and changes
the error handling to be closer the ModuleTranslation. In particular,
processValue -> lookupValue and processType -> convertType
now fail if the translation fails (instead of returning an error),
which simplifies the error handling.
The revision prepares a follow up commit that will import
LLVMIR intrinsics using tablegen.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135349
If 'order(concurrent)' clause is specified, then the iterations of SIMD loop
can be executed concurrently.
This patch adds support for LLVM IR codegen via OMPIRBuilder for SIMD loop
with 'order(concurrent)' clause. The functionality added to OMPIRBuilder is
similar to the functionality implemented in 'CodeGenFunction::EmitOMPSimdInit'.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D134046
Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>
The revision enriches the debug locations generated during LLVMIR to MLIR translation with file name information and adds a separate test to exercise the debug location translation.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D135069
If any of the operands for FCmpOp is a vector, returns a vector<Nxi1>,
rather than an i1 type result.
Differential Revision: https://reviews.llvm.org/D134449
Previously in mlir-translate, if debug info was absent in a
llvm::Instruction, we tried to create one using the name of its defined
value in a textual LLVM IR file as the (pseudo) debug file name.
However, in order to get that name, we need to call out to LLVM's
SlotTracker, which, surprisingly, took a lot of time. Judging from
the usefulness of such pseudo debug file name and the performance penalty
during translation, this patch simply use "imported-bitcode" as the
debug file name in these case. Eliminating the need of using (expensive)
LLVM value numbering.
Differential Revision: https://reviews.llvm.org/D134305
This adds support for pointer DLTI entries in LLVMIR export, e.g.
```
// translated to: p0:32:64:128
#dlti.dl_entry<!llvm.ptr, dense<[32,64,128]> : vector<3xi32>>
// translated to: p1:32:32:32:64
#dlti.dl_entry<!llvm.ptr<1>, dense<[32,32,32,64]> : vector<4xi32>>
```
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D133434
839b436c93
changes the behavior. Based on the discussion, we also want to support
"and" behavior. The revision changes it into two functions, bitEnumContainsAny
and bitEnumContainsAll.
Reviewed By: krzysz00, antiagainst
Differential Revision: https://reviews.llvm.org/D133507
