This flag was used to let us incrementally introduce debug records
into LLVM, however everything is now using records. It serves no
purpose now, so delete it.
This commit introduces the `import-structs-as-literals` option to the
MLIR import. This ensures that all struct types are imported as literal
structs, even when they are named in LLVM IR.
Currently, there is no common mechanism for supported intrinsics to be
generically annotated with arg and ret attributes. Since there are many
supported intrinsics around different dialects, the amount of work to
teach all them about these attributes is not trivial (though it would be
nice in the long term).
This PR adds a new flag `-prefer-unregistered-intrinsics` that can be
used alongside `--import-llvm` to always use `llvm.intrinsic_call`
during import time (ignoring dialect hooks for custom intrinsic
support).
Using this flag allow us to roundtrip the LLVM IR while eliminating a
whole set of differences coming from lack of arg/ret attributes on
supported intrinsics.
Note `convertIntrinsic` has to be moved to an implementation file
because it queries into `moduleImport` state, which is a fwd declaration
in `LLVMImportInterface.h`
* Strip calls to raw_string_ostream::flush(), which is essentially a no-op
* Strip unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
We are almost ready to enable the use of debug records everywhere in
LLVM by default; part of the prep-work for this means ensuring that
every tool supports them. Every tool in the `llvm/` project supports
them, front-ends that use the `DIBuilder` will support them, and as far
as I can tell, the only other tool in the LLVM repo that needs to
support them but doesn't is `mlir-translate`. This patch trivially
unblocks them by converting from debug records to debug intrinsics
before translating a module.
This commit introduces a flag to allow skipping the potentially
recursive import of DICompositeType elements. This patch is essentially a
bandaid for the still broken recursive debug type import.
Some of our downstream inputs are produced by excessive usage of
template meta programming, and thus contain tens of thousands of types
that all participate in such recursions. Unfortunately, the series of
patches that introduces type support is not easily revertible due to
being around for a while now and Modular depending on it.
We can consider to revert this change once the type importer has show to
be very performant, but for now we are talking second vs hours to import
specific files.
The revision adds a flag to the LLVM IR import
that avoids emitting expensive warnings about
unsupported debug intrinsics and unhandled
metadata.
Reviewed By: Dinistro
Differential Revision: https://reviews.llvm.org/D153625
This commit ensures that the importing of LLVM modules first verifies
that the module is even valid. As many tests did not work with valid
LLVM IR, they were fixed as part of this commit.
Some error messages were only reachable with invalid input IR, thus they
were replaced with a failures.
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D144186
The revision introduces the LLVMImportDialectInterface to make the
import of LLVM IR intrinsics extensible. It uses a dialect interface
that enables external projects to provide their own conversion functions
for custom intrinsics. These conversion functions can rely on the
ModuleImport class to perform support tasks such as mapping LLVM
values to MLIR values or for converting types between the two worlds.
The implementation largely mirrors the export implementation. One major
difference is the dispatch to the appropriate dialect interface, since
LLVM IR intrinsics have no direct association to an MLIR dialect. The
dialect interfaces thus have to publish the supported intrinsics to
ensure incoming conversion calls are dispatched to the right dialect
interface.
The revision implements the extensible intrinsic import discussed as
part of the "extensible llvm ir import" rfc:
https://discourse.llvm.org/t/rfc-extensible-llvm-ir-import/67256/6
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D140374
The revision renames the Importer to ModuleImport and moves the class
out of the ConvertFromLLVMIR.cpp file into ModuleImport.h and
ModuleImport.cpp. Additionally, it introduces two helper methods
on the ModuleImport class that convert functions and globals, and it
merges the translateLLVMIRToModule function into the
registerFromLLVMIRTranslation function to match the design of
the MLIR to LLVM IR export.
This restructuring is a step towards the file structure of the export
and a preparation for an extensible import
https://discourse.llvm.org/t/rfc-extensible-llvm-ir-import/67256/6 that
uses a dialect interface to import intrinsics and metadata.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D140285
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This revision adds support to import fastmath flags from LLVMIR. It
implement the import using a listener attached to the builder. The
listener gets notified if an operation is created and then checks if
there are fastmath flags to import from LLVM IR to the MLIR. The
listener based approach allows us to perform the import without changing
the mlirBuilders used to create the imported operations.
An alternative solution, could be to update the builders so that they
return the created operation using FailureOr<Operation*> instead of
LogicalResult. However, this solution implies an LLVM IR instruction
always maps to exatly one MLIR operation. While mostly true, there are
already exceptions to this such as the PHI instruciton. Additionally, an
mlirBuilder based solution also further complicates the builder
implementations, which led to the listener based solution.
Depends on D139405
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D139620
The revision adds an inbounds attribute to the LLVM dialect
GEP operation. It extends the builders and the import and export
to support the optional inbounds attribute.
As all builders set inbounds to false by default, existing lowerings
from higher-level dialects to LLVM dialect are not affected by the
change. Canonicalization/folding remains untouched since it currently
does not implement any simplifications in case of undefined behavior
(the handling of undefined behavior is deferred to LLVM).
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D139821
The recently introduced iterative constant import
(https://reviews.llvm.org/D137559) fails for programs that
subsequently import constant expressions with duplicate
subexpressions. The reason is a broken duplicate check
in getConstantsToConvert. The revision fixes the bug and
adds a test case that imports two constant expressions
with duplicates.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D139918
Instead of exiting in the middle of the import handle errors more
gracefully by printing an error message and returning failure. The
revision handles and tests the import of unsupported instructions,
values, constants, and intrinsics.
Depends on D139404
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D139405
Modernize the import of LLVMIR instructions and global variables.
Use longer variable names, factor out code used to import call or
invoke instructions, use the CPP builders for importing branch
instructions, etc. The revision is a preparation for a follow up
revision that moves the import code to implement improved error
handling.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D139404
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
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
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
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
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
With the transition to opaque pointers, type information has been
transferred to function parameter attributes. This patch adds correct
parsing for some of those arguments and fixes some tests, that
previously used UnitAttr for those.
Differential Revision: https://reviews.llvm.org/D132366
The attribute is translated into LLVM's function attribute 'readnone'.
There is no explicit verification regarding conflicting 'readnone'
and function attributes from 'passthrough', though, LLVM would assert
if they are incompatible during LLVM IR creation.
Differential Revision: https://reviews.llvm.org/D131457
This patch moves `LLVM::ShuffleVectorOp` to assembly format and in the
process drops the extra type that can be inferred (both operand types
are required to be the same) and switches to a dense integer array.
The syntax change:
```
// Before
%0 = llvm.shufflevector %0, %1 [0 : i32, 0 : i32, 0 : i32, 0 : i32] : vector<4xf32>, vector<4xf32>
// After
%0 = llvm.shufflevector %0, %1 [0, 0, 0, 0] : vector<4xf32>
```
Reviewed By: dcaballe
Differential Revision: https://reviews.llvm.org/D132038
This reland includes changes to the Python bindings.
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131801
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131803
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131738
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D131702
