[mlir] Use value instead of getValue (NFC)

[mlir] Use has_value instead of hasValue (NFC)

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[mlir][LLVMIR] Use insertelement if needed when translating ConstantAggregate

When translating from a llvm::ConstantAggregate with vector type, we
should lower to insertelement operations (if needed

[mlir][LLVMIR] Use insertelement if needed when translating ConstantAggregate

When translating from a llvm::ConstantAggregate with vector type, we
should lower to insertelement operations (if needed) rather than using
insertvalue.

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

show more ...

[mlir] Support import llvm intrinsics.

This patch supports to convert the llvm intrinsic to the corresponding op. It still leaves some intrinsics to be handled specially.

Reviewed By: ftynse

Diffe

[mlir] Support import llvm intrinsics.

This patch supports to convert the llvm intrinsic to the corresponding op. It still leaves some intrinsics to be handled specially.

Reviewed By: ftynse

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

show more ...

[mlir][LLVM] Add support for Calling Convention in LLVMFuncOp

This patch adds support for Calling Convention attribute in LLVM
dialect, including enums, custom syntax and import from LLVM IR.
Additi

[mlir][LLVM] Add support for Calling Convention in LLVMFuncOp

This patch adds support for Calling Convention attribute in LLVM
dialect, including enums, custom syntax and import from LLVM IR.
Additionally fix import of dso_local attribute.

Reviewed By: ftynse

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

show more ...

[mlir][LLVMIR] Add support for translating from some simple LLVM instructions

Add support for translating from llvm::Select, llvm::FNeg, and llvm::Unreachable.
This patch also cleans up (NFC) the op

[mlir][LLVMIR] Add support for translating from some simple LLVM instructions

Add support for translating from llvm::Select, llvm::FNeg, and llvm::Unreachable.
This patch also cleans up (NFC) the opcode map for simple instructions and
adds `// clang-format off/on` comments to prevent those lines from being
churned by clang-format between commits.

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

show more ...

[mlir][LLVMIR] Use a new way to verify GEPOp indices

Previously, GEPOp relies on `findKnownStructIndices` to check if a GEP
index should be static. The truth is, `findKnownStructIndices` can only
te

[mlir][LLVMIR] Use a new way to verify GEPOp indices

Previously, GEPOp relies on `findKnownStructIndices` to check if a GEP
index should be static. The truth is, `findKnownStructIndices` can only
tell you a GEP index _might_ be indexing into a struct (which should use
a static GEP index). But GEPOp::build and GEPOp::verify are falsely
taking this information as a certain answer, which creates many false
alarms like the one depicted in
`test/Target/LLVMIR/Import/dynamic-gep-index.ll`.

The solution presented here adopts a new verification scheme: When we're
recursively checking the child element types of a struct type, instead
of checking every child types, we only check the one dictated by the
(static) GEP index value. We also combine "refinement" logics --
refine/promote struct index mlir::Value into constants -- into the very
verification process since they have lots of logics in common. The
resulting code is more concise and less brittle.

We also hide GEPOp::findKnownStructIndices since most of the
aforementioned logics are already encapsulated within GEPOp::build and
GEPOp::verify, we found little reason for findKnownStructIndices (or the
new findStructIndices) to be public.

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

show more ...

[mlir][LLVMIR] Add support for translating insertelement/extractelement.

Add support for translating llvm::InsertElement and llvm::ExtractElement.

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

[mlir][LLVMIR] Add support for translating insertelement/extractelement.

Add support for translating llvm::InsertElement and llvm::ExtractElement.

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

show more ...

[mlir][LLVMIR] Add support for translating shufflevector

Add support for translating llvm::ShuffleVectorInst

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

[mlir][LLVMIR] Add support for translating insert/extractvalue

Add support for translating llvm::InsertValue and llvm::ExtractValue.

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

[mlir][LLVMIR] Do not update instMap via assignments to entry references

Inside processInstruction, we assign the translated mlir::Value to a
reference previously taken from the corresponding entry

[mlir][LLVMIR] Do not update instMap via assignments to entry references

Inside processInstruction, we assign the translated mlir::Value to a
reference previously taken from the corresponding entry in instMap.
However, instMap (a DenseMap) might resize after the entry reference was
taken, rendering the assignment useless since it's assigning to a
dangling reference. Here is a (pseudo) snippet that shows the concept:
```
// inst has type llvm::Instruction *
Value &v = instMap[inst];
...
// op is one of the operands of inst, has type llvm::Value *
processValue(op);
// instMap resizes inside processValue
...
translatedValue = b.createOp<Foo>(...);
// v is already a dangling reference at this point!
// The following assignment is bogus.
v = translatedValue;
```

Nevertheless, after we stop caching llvm::Constant into instMap, there
is only one case that can cause processValue to resize instMap: If the
operand is a llvm::ConstantExpr. In which case we will insert the
derived llvm::Instruction into instMap.
To trigger instMap to resize, which is a DenseMap, the threshold depends
on the ratio between # of map entries and # of (hash) buckets. More specifically,
it resizes if (# of map entries / # of buckets) >= 0.75.
In this case # of map entries is equal to # of LLVM instructions, and # of
buckets is the power-of-two upperbound of # of map entries. Thus, eventually
in the attaching test case (test/Target/LLVMIR/Import/incorrect-instmap-assignment.ll),
we picked 96 and 128 for the # of map entries and # of buckets, respectively.
(We can't pick numbers that are too small since DenseMap used inlined
storage for small number of entries). Therefore, the ConstantExpr in the
said test case (i.e. a GEP) is the 96-th llvm::Value cached into the
instMap, triggering the issue we're discussing here on its enclosing
instruction (i.e. a load).

This patch fixes this issue by calling `operator[]` everytime we need to
update an entry.

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

show more ...

[mlir][LLVMIR] Add support for translating Switch instruction

Add support for translating llvm::SwitchInst.

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

[mlir][LLVMIR] Add support for translating FCmp & FP constants

This patch add supports for translating FCmp and more kinds of FP
constants in addition to 32 & 64-bit ones. However, we can't express

[mlir][LLVMIR] Add support for translating FCmp & FP constants

This patch add supports for translating FCmp and more kinds of FP
constants in addition to 32 & 64-bit ones. However, we can't express
ppc_fp128 constants right now because the semantics for its underlying
APFloat is `S_PPCDoubleDouble` but mlir::FloatType doesn't support such
semantics right now.

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

show more ...

[mlir][LLVMIR] Do not cache llvm::Constant into instMap

Constants in MLIR are not globally unique, unlike that in LLVM IR.
Therefore, reusing previous-translated constants might cause the user
opera

[mlir][LLVMIR] Do not cache llvm::Constant into instMap

Constants in MLIR are not globally unique, unlike that in LLVM IR.
Therefore, reusing previous-translated constants might cause the user
operations not being dominated by the constant (because the
previous-translated ones can be placed in arbitrary place)

This indeed misses some opportunities where we actually can reuse a
previous-translated constants, but verbosity is not our first priority
here.

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

show more ...

[mlir][LLVMIR] Do not cache Instruction generated on-the-fly

More specifically, the llvm::Instruction generated by
llvm::ConstantExpr::getAsInstruction. Such Instruction will be deleted
right away,

[mlir][LLVMIR] Do not cache Instruction generated on-the-fly

More specifically, the llvm::Instruction generated by
llvm::ConstantExpr::getAsInstruction. Such Instruction will be deleted
right away, but it's possible that when getAsInstruction is called
again, it will create a new Instruction that has the same address with
the one we just deleted. Thus, we shouldn't keep it in the `instMap` to
avoid a conflicting index that triggers an assertion in
processInstruction.

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

show more ...

[mlir][LLVMIR] Add support for importing struct-type ConstantAggregate(Zero)

And move importer test files from `test/Target/LLVMIR` into
`test/Target/LLVMIR/Import`.

We simply translate struct-type

[mlir][LLVMIR] Add support for importing struct-type ConstantAggregate(Zero)

And move importer test files from `test/Target/LLVMIR` into
`test/Target/LLVMIR/Import`.

We simply translate struct-type ConstantAggregate(Zero) into a
serious of `llvm.insertvalue` operations against a `llvm.undef` root.
Note that this doesn't affect the original logics on translating
vector/array-type ConstantAggregate values.

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

show more ...

[mlir] Support opaque types in LLVM IR -> MLIR translation

LLVM IR is moving towards adoption of opaque pointer types. These require extra
information to be passed when constructing some operations,

[mlir] Support opaque types in LLVM IR -> MLIR translation

LLVM IR is moving towards adoption of opaque pointer types. These require extra
information to be passed when constructing some operations, in particular GEP
and Alloca. Adapt the builders of said operations and modify the translation
code to handle both opaque and non-opaque pointers.

This incidentally adds the translation for Alloca alignment and fixes the translation
of struct-related GEP indices that must be constant.

Reviewed By: wsmoses

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

show more ...

[mlir][LLVM-IR] Added support for global variable attributes

This patch adds thread_local to llvm.mlir.global and adds translation for dso_local and addr_space to and from LLVM IR.

Reviewed By: Mog

[mlir][LLVM-IR] Added support for global variable attributes

This patch adds thread_local to llvm.mlir.global and adds translation for dso_local and addr_space to and from LLVM IR.

Reviewed By: Mogball

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

show more ...

[mlir] Make OpBuilder::createOperation to accept raw inputs

This provides a way to create an operation without manipulating
OperationState directly. This is useful for creating unregistered ops.

Re

[mlir] Make OpBuilder::createOperation to accept raw inputs

This provides a way to create an operation without manipulating
OperationState directly. This is useful for creating unregistered ops.

Reviewed By: rriddle, mehdi_amini

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

show more ...

[mlir][NFC] Move Translation.h to a Tools/mlir-translate directory

Translation.h is currently awkwardly shoved into the top-level mlir, even though it is
specific to the mlir-translate tool. This co

[mlir][NFC] Move Translation.h to a Tools/mlir-translate directory

Translation.h is currently awkwardly shoved into the top-level mlir, even though it is
specific to the mlir-translate tool. This commit moves it to a new Tools/mlir-translate
directory, which is intended for libraries used to implement tools. It also splits the
translate registry from the main entry point, to more closely mirror what mlir-opt
does.

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

show more ...

[MLIR] Use Datalayout defaults when importing LLVM

LLVM defines several default datalayouts for integer and floating point types that are not being considered when importing into MLIR. This patch re

[MLIR] Use Datalayout defaults when importing LLVM

LLVM defines several default datalayouts for integer and floating point types that are not being considered when importing into MLIR. This patch remedies this.

Reviewed By: ftynse

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

show more ...

[mlir] Add partial support for translating data layout

Add support for translating data layout specifications for integer and float
types between MLIR and LLVM IR. This is a first step towards remov

[mlir] Add partial support for translating data layout

Add support for translating data layout specifications for integer and float
types between MLIR and LLVM IR. This is a first step towards removing the
string-based LLVM dialect data layout attribute on modules. The latter is still
available and will remain so until the first-class MLIR modeling can fully
replace it.

Depends On D120739

Reviewed By: wsmoses

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

show more ...

[mlir][LLVM] Add support for adding a garbage collector to a LLVM function

This patch simply adds an optional garbage collector attribute to LLVMFuncOp which maps 1:1 to the "gc" property of functio

[mlir][LLVM] Add support for adding a garbage collector to a LLVM function

This patch simply adds an optional garbage collector attribute to LLVMFuncOp which maps 1:1 to the "gc" property of functions in LLVM.

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

show more ...