[mlir][LLVM] Add OpBuilder for opaque pointer GEPs without struct indices

An OpBuilder already exists for GEPs that does not have any struct indices for existing typed pointers, but no such builder

[mlir][LLVM] Add OpBuilder for opaque pointer GEPs without struct indices

An OpBuilder already exists for GEPs that does not have any struct indices for existing typed pointers, but no such builder exists for GEPs utilizing opaque pointers that has an explicit `basePtrType`.

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

show more ...

[mlir] (NFC) run clang-format on all files

[mlir] Use value instead of getValue (NFC)

[mlir] Use has_value instead of hasValue (NFC)

[mlir][LLVMIR] Apply CallOp/CallableInterface on suitable operations

- Applying CallOpInterface on CallOp and InvokeOp.
- Applying CallableInterface on LLVMFuncOp.

We're testing the changes usi

[mlir][LLVMIR] Apply CallOp/CallableInterface on suitable operations

- Applying CallOpInterface on CallOp and InvokeOp.
- Applying CallableInterface on LLVMFuncOp.

We're testing the changes using CallGraph, which uses both interfaces.

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

show more ...

[mlir][LLVMIR] Add support for va_start/copy/end intrinsics

This patch adds three new LLVM intrinsic operations: llvm.intr.vastart/copy/end.
And its translation from LLVM IR.

This effectively remov

[mlir][LLVMIR] Add support for va_start/copy/end intrinsics

This patch adds three new LLVM intrinsic operations: llvm.intr.vastart/copy/end.
And its translation from LLVM IR.

This effectively removes a restriction, imposed by 0126dcf1f0a1, where
non-external functions in LLVM dialect cannot be variadic. At that time
it was not clear how LLVM intrinsics are going to be modeled, which
indirectly affects va_start/copy/end, the core intrinsics used in
variadic functions. But since we have LLVM intrinsics as normal
MLIR operations, it's not a problem anymore.

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

show more ...

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

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[mlir] Don't use Optional::getValue (NFC)

Don't use Optional::hasValue (NFC)

[mlir] Don't use Optional::hasValue (NFC)

[mlir][LLVMIR] Ask ICmpOp to return vector<Nxi1> when needed

If any of the operands for ICmpOp is a vector, returns a vector<Nxi1>
, rather than an i1 type result.

Differential Revision: https://re

[mlir][LLVMIR] Ask ICmpOp to return vector<Nxi1> when needed

If any of the operands for ICmpOp is a vector, returns a vector<Nxi1>
, rather than an i1 type result.

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

show more ...

[mlir][LLVMIR] Use isScalableVectorType in ShuffleVectorOp::parse

Instead of casting the incoming operand into VectorType to check if it's
scalable or not.
This is the place I missed to fix in f088b

[mlir][LLVMIR] Use isScalableVectorType in ShuffleVectorOp::parse

Instead of casting the incoming operand into VectorType to check if it's
scalable or not.
This is the place I missed to fix in f088b99eac74.

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

show more ...

[mlir][llvm] Fix compiler error on GCC 9

This patch fixes the following compiler error:

error: declaration of ‘mlir::LLVM::cconv::CConv mlir::LLVM::detail::CConvAttrStorage::CConv’ changes mean

[mlir][llvm] Fix compiler error on GCC 9

This patch fixes the following compiler error:

error: declaration of ‘mlir::LLVM::cconv::CConv mlir::LLVM::detail::CConvAttrStorage::CConv’ changes meaning of ‘CConv’ [-fpermissive]

CConv as a member variable name was shadowing CConv as an enumeration,
hence the compiler error.

Reviewed By: ftynse, alexbatashev

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

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] Use the correct way to determine if it's a scalable vector

One of the ShuffleVectorOp::build functions checks if the incoming
vector operands is scalable vector by casting its type to

[mlir][LLVMIR] Use the correct way to determine if it's a scalable vector

One of the ShuffleVectorOp::build functions checks if the incoming
vector operands is scalable vector by casting its type to
mlir::VectorType first. However, in some cases the operand is not
necessarily mlir::VectorType (e.g. it might be a LLVMVectorType).

This patch fixes this issue by using the dedicated
`LLVM::isScalableVectorType` function to determine if the incoming
vector is scalable vector or not.

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

show more ...

[mlir] Update LLVMIR Fastmath flags use of MLIR BitEnum functionality

This diff updates the LLVMIR dialect Fastmath flags attribute to use recently
added features of `BitEnum` attributes. Specifical

[mlir] Update LLVMIR Fastmath flags use of MLIR BitEnum functionality

This diff updates the LLVMIR dialect Fastmath flags attribute to use recently
added features of `BitEnum` attributes. Specifically, this diff uses the bit
enum "group" case to represent the `fast` value as an alias for a combination
of other values (`ninf`, `nnan`, ...), instead of using a separate integer
value. (This is in line with LLVM's fastmath flags representation.) This diff
also leverages the `printBitEnumPrimaryGroups` `tblgen` field for concise
enum printing.

The `BitEnum` features were developed for an upcoming diff that adds `fastmath`
support to the arithmetic dialect. This diff simply applies some of the relevant
new features to the LLVM dialect attribute.

Reviewed By: ftynse, Mogball

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

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 ...

[ParseResult] Mark this as LLVM_NODISCARD (like LogicalResult) and fix issues.

There are a lot of cases where we accidentally ignored the result of some
parsing hook. Mark ParseResult as LLVM_NODIS

[ParseResult] Mark this as LLVM_NODISCARD (like LogicalResult) and fix issues.

There are a lot of cases where we accidentally ignored the result of some
parsing hook. Mark ParseResult as LLVM_NODISCARD just like ParseResult is.
This exposed some stuff to clean up, so do.

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

show more ...

[mlir] Refactoring dialect and test code to use parseCommaSeparatedList

Issue #55173

Reviewed By: lattner, rriddle

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

[AsmParser] Introduce a new "Argument" abstraction + supporting logic

MLIR has a common pattern for "arguments" that uses syntax
like `%x : i32 {attrs} loc("sourceloc")` which is implemented
in adho

[AsmParser] Introduce a new "Argument" abstraction + supporting logic

MLIR has a common pattern for "arguments" that uses syntax
like `%x : i32 {attrs} loc("sourceloc")` which is implemented
in adhoc ways throughout the codebase. The approach this uses
is verbose (because it is implemented with parallel arrays) and
inconsistent (e.g. lots of things drop source location info).

Solve this by introducing OpAsmParser::Argument and make addRegion
(which sets up BlockArguments for the region) take it. Convert the
world to propagating this down. This means that we correctly
capture and propagate source location information in a lot more
cases (e.g. see the affine.for testcase example), and it also
simplifies much code.

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

show more ...

[AsmParser] Rework logic around "region argument parsing"

The asm parser had a notional distinction between parsing an
operand (like "%foo" or "%4#3") and parsing a region argument
(which isn't supp

[AsmParser] Rework logic around "region argument parsing"

The asm parser had a notional distinction between parsing an
operand (like "%foo" or "%4#3") and parsing a region argument
(which isn't supposed to allow a result number like #3).

Unfortunately the implementation has two problems:

1) It didn't actually check for the result number and reject
it. parseRegionArgument and parseOperand were identical.
2) It had a lot of machinery built up around it that paralleled
operand parsing. This also was functionally identical, but
also had some subtle differences (e.g. the parseOptional
stuff had a different result type).

I thought about just removing all of this, but decided that the
missing error checking was important, so I reimplemented it with
a `allowResultNumber` flag on parseOperand. This keeps the
codepaths unified and adds the missing error checks.

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

show more ...

[mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`

The verifier of llvm.mlir.addressof did not properly account for opaque pointers, that is, the pointer type not having an element type e

[mlir][LLVM] Support opaque pointers in `llvm.mlir.addressof`

The verifier of llvm.mlir.addressof did not properly account for opaque pointers, that is, the pointer type not having an element type equal to the type of the referenced global or function. This patch fixes that by skipping the test for the element type if the pointer is opaque.

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

show more ...

[AsmParser/Printer] Rework sourceloc support for function arguments.

When Location tracking support for block arguments was added, we
discussed various approaches to threading support for this throu

[AsmParser/Printer] Rework sourceloc support for function arguments.

When Location tracking support for block arguments was added, we
discussed various approaches to threading support for this through
function-like argument parsing. At the time, we added a parallel array
of locations that could hold this. It turns out that that approach was
verbose and error prone, roughly no one adopted it.

This patch takes a different approach, adding an optional source
locator to the UnresolvedOperand class. This fits much more naturally
into the standard structure we use for representing locators, and gives
all the function like dialects locator support for free (e.g. see the
test adding an example for the LLVM dialect).

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

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 ...