aboutsummaryrefslogtreecommitdiff
path: root/mlir/lib/Target/LLVMIR/ModuleImport.cpp
AgeCommit message (Collapse)AuthorFilesLines
7 days[MLIR] Apply clang-tidy fixes for bugprone-argument-comment in ↵Mehdi Amini1-3/+3
ModuleImport.cpp (NFC)
10 days[MLIR] Apply clang-tidy fixes for llvm-qualified-auto in ModuleImport.cpp (NFC)Mehdi Amini1-2/+2
2025-09-01[MLIR] Add target_specific_attrs attribute to mlir.global (#154706)Vadim Curcă1-53/+73
Adds a `target_specific_attrs` optional array attribute to `mlir.global`, as well as conversions to and from LLVM attributes on `llvm::GlobalVariable` objects. This is necessary to preserve unknown attributes on global variables when converting to and from the LLVM Dialect. Previously, any attributes on an `llvm::GlobalVariable` not explicitly modeled by `mlir.global` were dropped during conversion.
2025-08-29[IR][CodeGen] Remove "approx-func-fp-math" attribute (#155740)paperchalice1-5/+0
Remove "approx-func-fp-math" attribute and related command line option, users should always use afn flag in IR. Resolve FIXME in `TargetMachine::resetTargetOptions` partially.
2025-08-20[MLIR][LLVMIR][DLTI] Add `LLVM::TargetAttrInterface` and `#llvm.target` attr ↵Rolf Morel1-4/+5
(#145899) Adds the `#llvm.target<triple = $TRIPLE, chip = $CHIP, features = $FEATURES>` attribute and along with a `-llvm-target-to-data-layout` pass to derive a MLIR data layout from the LLVM data layout string (using the existing `DataLayoutImporter`). The attribute implements the relevant DLTI-interfaces, to expose the `triple`, `chip` (AKA `cpu`) and `features` on `#llvm.target` and the full `DataLayoutSpecInterface`. The pass combines the generated `#dlti.dl_spec` with an existing `dl_spec` in case one is already present, e.g. a `dl_spec` which is there to specify size of the `index` type. Adds a `TargetAttrInterface` which can be implemented by all attributes representing LLVM targets. Similar to the Draft PR https://github.com/llvm/llvm-project/pull/78073. RFC on which this PR is based: https://discourse.llvm.org/t/mandatory-data-layout-in-the-llvm-dialect/85875
2025-07-31[mlir][llvm] adds an attribute for the module level assembly (#151318)gitoleg1-0/+14
Adds support for the module level assembly in the LLVM IR dialect. --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
2025-07-30Reapply "[mlir][llvm] Add intrinsic arg and result attribute support … ↵Tobias Gysi1-28/+24
(#151324) …(… (#151099) This reverts commit 2780b8f22058b35a8e70045858b87a1966df8df3 and relands b7bfbc0c4c7b20d6623a5b0b4a7fea8ae08a62da. Adds the following fixes compared to the original PR (https://github.com/llvm/llvm-project/pull/150783): - A bazel fix - Use `let methods` instead of `list<InterfaceMethod> methods` The missing forward declaration has been added in meantime: https://github.com/llvm/llvm-project/commit/9164d206b33d61c93f5fc4628797485f96d654ca.
2025-07-30Revert "Reland "[mlir][llvm] Add intrinsic arg and result attribute support ↵Mehdi Amini1-24/+28
(…" (#151316) Reverts llvm/llvm-project#151125 Broke the gcc-7 build: include/mlir/Target/LLVMIR/ModuleTranslation.h:318:34: error: no type named 'CallBase' in namespace 'llvm' llvm::CallBase *call, ~~~~~~^
2025-07-30Reland "[mlir][llvm] Add intrinsic arg and result attribute support (… ↵Tobias Gysi1-28/+24
(#151125) …… (#151099) This reverts commit 2780b8f22058b35a8e70045858b87a1966df8df3 to reland 59013d44058ef423a117f95092150e16e16fdb09. In addition to the original commit this one includes: - This includes a bazel fix - Use `let methods` instead of `list<InterfaceMethod> methods` The original commit message was: This patch extends the LLVM dialect's intrinsic infra to support argument and result attributes. Initial support is added for the memory intrinsics llvm.intr.memcpy, llvm.intr.memmove, and llvm.intr.memset. Additionally, an ArgAndResultAttrsOpInterface is factored out of CallOpInterface and CallableOpInterface, enabling operations to have argument and result attributes without requiring them to be a call or a callable operation.
2025-07-29Revert "[mlir][llvm] Add intrinsic arg and result attribute support (… ↵Tobias Gysi1-24/+28
(#151099) …#150783)" This reverts commit 59013d44058ef423a117f95092150e16e16fdb09. The change breaks a flang build bot: https://lab.llvm.org/buildbot/#/builders/207/builds/4441
2025-07-29[mlir][llvm] Add intrinsic arg and result attribute support (#150783)Tobias Gysi1-28/+24
This patch extends the LLVM dialect's intrinsic infra to support argument and result attributes. Initial support is added for the memory intrinsics `llvm.intr.memcpy`, `llvm.intr.memmove`, and `llvm.intr.memset`. Additionally, an ArgAndResultAttrsOpInterface is factored out of CallOpInterface and CallableOpInterface, enabling operations to have argument and result attributes without requiring them to be a call or a callable operation.
2025-07-25[mlir][NFC] update `mlir` create APIs (34/n) (#150660)Maksim Levental1-20/+19
See https://github.com/llvm/llvm-project/pull/147168 for more info.
2025-07-22[mlir][NFC] update `mlir/lib` create APIs (26/n) (#149933)Maksim Levental1-70/+71
See https://github.com/llvm/llvm-project/pull/147168 for more info. --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
2025-07-17[mlir][LLVMIR] Add IFuncOp to LLVM dialect (#147697)Robert Konicar1-6/+42
Add IFunc to LLVM dialect and add support for lifting/exporting LLVMIR IFunc.
2025-07-05[mlir] Remove unused includes (NFC) (#147158)Kazu Hirata1-1/+0
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2025-06-10[flang] Add support for -mrecip[=<list>] (#143418)Cameron McInally1-0/+5
This patch adds support for the -mrecip command line option. The parsing of this options is equivalent to Clang's and it is implemented by setting the "reciprocal-estimates" function attribute. Also move the ParseMRecip(...) function to CommonArgs, so that Flang is able to make use of it as well. --------- Co-authored-by: Cameron McInally <cmcinally@nvidia.com>
2025-05-30[flang] Add support for -mprefer-vector-width=<value> (#142073)Cameron McInally1-0/+4
This patch adds support for the -mprefer-vector-width= command line option. The parsing of this options is equivalent to Clang's and it is implemented by setting the "prefer-vector-width" function attribute. Co-authored-by: Cameron McInally <cmcinally@nvidia.com>
2025-05-22[MLIR][LLVM] Tail call support for inline asm op (#140826)Bruno Cardoso Lopes1-0/+1
2025-05-21[mlir] Remove unused local variables (NFC) (#140990)Kazu Hirata1-1/+0
2025-05-16[MLIR][LLVM] Add import-structs-as-literals flag to the IR import (#140098)Christian Ulmann1-4/+7
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.
2025-05-15[MLIR][LLVM] Improve inline asm importer (#139989)Bruno Cardoso Lopes1-3/+40
Add support for importing more information into InlineAsmOp: elementtype, side effects, align stack, asm dialect and operand attrs.
2025-05-12[NFC][MLIR] Add {} for `else` when `if` body has {} (#139422)Rahul Joshi1-1/+2
2025-05-05[MLIR][LLVMIR] Import calls with mismatching signature as indirect call ↵Bruno Cardoso Lopes1-17/+55
(#135895) LLVM IR currently [accepts](https://godbolt.org/z/nqnEsW1ja): ``` define void @incompatible_call_and_callee_types() { call void @callee(i64 0) ret void } define void @callee({ptr, i64}, i32) { ret void } ``` This currently fails to import. Even though these constructs are dangerous and probably indicate some ODR violation (or optimization bug), they are "valid" and should be imported into LLVM IR dialect. This PR implements that by using an indirect call to represent it. Translation already works nicely and outputs the same source llvm IR file. The error is now a warning, the tests in `mlir/test/Target/LLVMIR/Import/import-failure.ll` already use `CHECK` lines, so no need to add extra diagnostic tests.
2025-05-05[MLIR][LLVM] Add ProfileSummary module flag support (#138070)Bruno Cardoso Lopes1-5/+277
Add one more of these module flags. Unlike "CG Profile", LLVM proper does not verify the content of the metadata, but returns a nullptr in case it's ill-formed (it's up to the user to take action). This prompted me to implement warning checks, preventing the importer to consume broken data.
2025-04-30[llvm][mlir] Adding instrument function entry and instrument function exit ↵Anchu Rajendran S1-0/+12
attributes (#137856)
2025-04-30[mlir][llvm] Support nusw and nuw in GEP (#137272)Peiyong Lin1-2/+3
nusw and nuw were introduced in getelementptr, this patch plumbs them in MLIR. Since inbounds implies nusw, this patch also adds an inboundsFlag to represent the concept of raw inbounds with no nusw implication, and have the inbounds literal captured as the combination of inboundsFlag and nusw. Fixes: iree#20482 Signed-off-by: Lin, Peiyong <linpyong@gmail.com>
2025-04-28[MLIR][LLVM] More on CG Profile: support null function entries (#137269)Bruno Cardoso Lopes1-6/+19
2025-04-24[MLIR][LLVM] Add CG Profile module flags support (#137115)Bruno Cardoso Lopes1-1/+39
Dialect only accept arbitrary module flag values in face of simple types like int and string. Whenever metadata is a bit more complex use specific attributes to map functionality. This PR adds an attribute to represent "CG Profile" entries, verifiers, import / translate support.
2025-04-23[MLIR][LLVM] Allow strings in module flag value (#136793)Bruno Cardoso Lopes1-6/+8
Expand support a bit beyond integers. Next step is to support more complex metadata values (e.g. !"CG Profile" and !"ProfileSummary"), but that's a bit more complex and deserves it own PR.
2025-04-21Reapply [MLIR][LLVM] Support for indirectbr (#136378)Bruno Cardoso Lopes1-2/+29
Fix msan issue that caused revert in https://github.com/llvm/llvm-project/pull/135695 ### Original message Now that LLVM dialect has `blockaddress` support, introduce import/translation for `indirectbr` instruction.
2025-04-17[MLIR:LLVM] Add UWTableKind attribute (#135811)Will Froom1-0/+7
Add `UWTableKind` enum and corresponding attribute to `llvm.func` including translation to `llvm::Function` attribute.
2025-04-14Revert "[MLIR][LLVM] Support for indirectbr" (#135695)Bruno Cardoso Lopes1-31/+2
Reverts llvm/llvm-project#135092, broke https://lab.llvm.org/buildbot/#/builders/169/builds/10469
2025-04-14[MLIR][LLVM] Support for indirectbr (#135092)Bruno Cardoso Lopes1-2/+31
Now that LLVM dialect has `blockaddress` support, introduce import/translation for `indirectbr` instruction.
2025-04-11[MLIR] Adding 'inline_hint' attribute on LLMV::CallOp (#134582)Jean-Didier PAILLEUX1-0/+1
Addition of `inlinehint` attributes for CallOps in MLIR in order to be able to say to a function call that the inlining is desirable without having the attribute on the FuncOp.
2025-04-09[mlir][LLVM] Delete `getVectorElementType` (#134981)Matthias Springer1-1/+1
The LLVM dialect no longer has its own vector types. It uses `mlir::VectorType` everywhere. Remove `LLVM::getVectorElementType` and use `cast<VectorType>(ty).getElementType()` instead. This commit addresses a [comment](https://github.com/llvm/llvm-project/pull/133286#discussion_r2022192500) on the PR that deleted the LLVM vector types. Also improve vector type constraints by specifying the `mlir::VectorType` C++ class, so that explicit casts to `VectorType` can be avoided in some places.
2025-04-07[MLIR][LLVM] Block address support (#134335)Bruno Cardoso Lopes1-3/+24
Add support for import and translate. MLIR does not support using basic block references outside a function (like LLVM does), This PR does not consider changes to MLIR to that respect. It instead introduces two new ops: `llvm.blockaddress` and `llvm.blocktag`. Here's an example: ``` llvm.func @ba() -> !llvm.ptr { %0 = llvm.blockaddress <function = @ba, tag = <id = 1>> : !llvm.ptr llvm.br ^bb1 ^bb1: // pred: ^bb0 llvm.blocktag <id = 1> llvm.return %0 : !llvm.ptr } ``` Value `%0` hold the address of block tagged as `id = 1` in function `@ba`. Block tags need to be unique within a function and use of `llvm.blockaddress` requires a matching tag in a `llvm.blocktag`.
2025-04-04[mlir][llvm] Add `LLVM_DependentLibrariesAttr` (#133385)Iris1-0/+19
https://llvm.org/docs/LangRef.html#dependent-libs-named-metadata --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
2025-04-01[MLIR] Adding 'no_inline' and 'always_inline' attributes on LLMV::CallOp ↵Jean-Didier PAILLEUX1-0/+3
(#133726) Addition of `no_inline` and `always_inline` attributes for CallOps in MLIR in order to be able to inline or not directly the call of a function without having the attribute on the `FuncOp`. The addition of these attributes will be used in a future PR in Flang (`[NO]INLINE` directive).
2025-03-27[MLIR][LLVMIR] Add support for the full form of global_{ctor,dtor} (#133176)Bruno Cardoso Lopes1-4/+11
Currently only ctor/dtor list and their priorities are supported. This PR adds support for the missing data field. Few implementation notes: - The assembly printer has a fixed form because previous `attr_dict` will sort the dict by key name, making global_dtor and global_ctor differ in the order of printed arguments. - LLVM's `ptr null` is being converted to `#llvm.zero` otherwise we'd have to create a region to use the default operation conversion from `ptr null`, which is silly given that the field only support null or a symbol.
2025-03-25[MLIR][LLVM] Fix debug value/declare import in face of landing pads (#132871)Bruno Cardoso Lopes1-1/+13
Debug value/declare operations imported before landing pad operations at the bb start break invoke op verification: ``` error: first operation in unwind destination should be a llvm.landingpad operation ``` This this issue by making the placement slightly more smart.
2025-03-24[MLIR][LLVM] Support dso_local_equivalent constants (#132131)Bruno Cardoso Lopes1-0/+21
Create a new operation `DSOLocalEquivalentOp`, following the steps of other constants. This is similar in a way to `AddressOfOp` but with specific semantics: only support functions and function aliases (no globals) and extern_weak linkage is not allowed. An alternative approach is to use a new `UnitAttr` in `AddressOfOp` and check that attribute to enforce specific semantics in the verifiers. The drawback is going against what other constants do and having to add more attributes in the future when we introduce `no_cfi`, `blockaddress`, etc. While here, improve the error message for other missing constants.
2025-03-20[mlir] Use *Set::insert_range (NFC) (#132326)Kazu Hirata1-1/+1
DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently gained C++23-style insert_range. This patch replaces: Dest.insert(Src.begin(), Src.end()); with: Dest.insert_range(Src); This patch does not touch custom begin like succ_begin for now.
2025-03-14[MLIR][LLVMIR] Import: add flag to prefer using unregistered intrinsics ↵Bruno Cardoso Lopes1-8/+10
(#130685) 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`
2025-03-14[MLIR][LLVMIR] Add module flags support (#130679)Bruno Cardoso Lopes1-0/+29
Import and translation support. Note that existing support (prior to this PR) already covers enough in translation specifically to emit "Debug Info Version". Also, the debug info version metadata is being emitted even though the imported IR has no information and is showing up in some tests (will fix that in another PR). --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com> Co-authored-by: Henrich Lauko <xlauko@mail.muni.cz>
2025-03-14[MLIR][LLVM] Import dereferenceable metadata from LLVM IR (#130974)mihailo-stojanovic1-0/+25
Add support for importing `dereferenceable` and `dereferenceable_or_null` metadata into LLVM dialect. Add a new attribute which models these two metadata nodes and a new OpInterface.
2025-03-07[MLIR][LLVMIR] Import: fix llvm.call attribute inheritance (#130221)Bruno Cardoso Lopes1-3/+8
`inst->getFnAttr(Kind)` fallbacks to check if the parent has an attribute, which breaks roundtriping the LLVM IR. This change actually checks only in the call attribute list (no fallback to parent queries). It's possible to argue that this small optimization isn't harmful, but seems too early if it's breaking roundtrip behavior.
2025-03-06[IR] Store Triple in Module (NFC) (#129868)Nikita Popov1-2/+3
The module currently stores the target triple as a string. This means that any code that wants to actually use the triple first has to instantiate a Triple, which is somewhat expensive. The change in #121652 caused a moderate compile-time regression due to this. While it would be easy enough to work around, I think that architecturally, it makes more sense to store the parsed Triple in the module, so that it can always be directly queried. For this change, I've opted not to add any magic conversions between std::string and Triple for backwards-compatibilty purses, and instead write out needed Triple()s or str()s explicitly. This is because I think a decent number of them should be changed to work on Triple as well, to avoid unnecessary conversions back and forth. The only interesting part in this patch is that the default triple is Triple("") instead of Triple() to preserve existing behavior. The former defaults to using the ELF object format instead of unknown object format. We should fix that as well.
2025-03-06[mlir][nfc] De-duplicate tests from `Type::isIntOrFloat` (#129710)Andrzej Warzyński1-8/+3
This PR makes sure that we always use `Type::isIntOrFloat` rather than re-implementing this condition inline. Also, it removes `isScalarType` that effectively re-implemented this method.
2025-03-05[MLIR][LLVMIR] llvm.call_intrinsic: support operand/result attributes (#129640)Bruno Cardoso Lopes1-3/+13
Basically catch up with llvm.call and add support for translate and import to LLVM IR. This PR is split into two commits in case it's easier to review the refactoring part, which comes first (happy to split the PR if necessary). --------- Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
2025-02-28[MLIR][LLVMIR] Add support for empty global ctor/dtor lists (#128969)Bruno Cardoso Lopes1-3/+13
LLVM IR emitted in from C++ may contain `@llvm.global_ctors = appending global [0 x { i32, ptr, ptr }] zeroinitializer`. Before this PR, if we try to roundtrip code like this from the importer, we'll end up with nothing in place. Note that `llvm::appendToGlobalCtors` ignores empty lists and this PR uses the same approach as `llvm-as`, which doesn't use the utilities from `llvm/lib/Transforms/Utils/ModuleUtils.cpp` in order to build this - it calls into creating a global variable from scratch.