[MLIR][LLVM] Enable export of DISubprograms on function declarations (#78026)

This commit changes the MLIR to LLVMIR export to also attach subprogram
debug attachements to function declarations.
T

[MLIR][LLVM] Enable export of DISubprograms on function declarations (#78026)

This commit changes the MLIR to LLVMIR export to also attach subprogram
debug attachements to function declarations.
This commit additonally fixes the two passes that produce subprograms to
not attach the "Definition" flag to function declarations. This
otherwise results in invalid LLVM IR.

show more ...

Add more ZA modes (#77361)

Add more ZA modes

Adds the arm_shared_za and arm_preserves_za attributes to the existing
arm_new_za attribute. The functionality already exists in LLVM, so just

Add more ZA modes (#77361)

Add more ZA modes

Adds the arm_shared_za and arm_preserves_za attributes to the existing
arm_new_za attribute. The functionality already exists in LLVM, so just
"linking the pieces together".

For more details see:
https://arm-software.github.io/acle/main/acle.html#sme-attributes-relating-to-za

show more ...

[MLIR][LLVM] DI Expression Rewrite & Legalization (#77541)

Add a rewriter for DIExpressions & use it to run legalization patterns
before exporting to llvm (because LLVM dialect allows DI Expression

[MLIR][LLVM] DI Expression Rewrite & Legalization (#77541)

Add a rewriter for DIExpressions & use it to run legalization patterns
before exporting to llvm (because LLVM dialect allows DI Expressions
that may not be valid in LLVM IR).

The rewriter driver works similarly to the existing mlir rewriter
drivers, except it operates on lists of DIExpressionElemAttr (i.e.
DIExpressionAttr). Each rewrite pattern transforms a range of
DIExpressionElemAttr into a new list of DIExpressionElemAttr.

In addition, this PR sets up a place to add legalization patterns that
are broadly applicable internally to the LLVM dialect, and they will
always be applied prior to export. This PR adds one pattern for merging
fragment operators.

---------

Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>

show more ...

[mlir] Add global and program memory space handling to the data layout subsystem (#77367)

This patch is based on a previous PR https://reviews.llvm.org/D144657
that added alloca address space handl

[mlir] Add global and program memory space handling to the data layout subsystem (#77367)

This patch is based on a previous PR https://reviews.llvm.org/D144657
that added alloca address space handling to MLIR's DataLayout and DLTI
interface. This patch aims to add identical features to import and
access the global and program memory space through MLIR's
DataLayout/DLTI system.

show more ...

[mlir] support dialect attribute translation to LLVM IR (#75309)

Extend the `amendOperation` mechanism for translating dialect attributes
attached to operations from another dialect when translatin

[mlir] support dialect attribute translation to LLVM IR (#75309)

Extend the `amendOperation` mechanism for translating dialect attributes
attached to operations from another dialect when translating MLIR to
LLVM IR. Previously, this mechanism would have no knowledge of the LLVM
IR instructions created for the given operation, making it impossible
for it to perform local modifications such as attaching operation-level
metadata. Collect instructions inserted by the LLVM IR builder and pass
them to `amendOperation`.

show more ...

[mlir] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[mlir] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[mlir][ArmSME] Add sve streaming compatible attribute (#75222)

Following the same path already used for ArmStreaming and
ArmLocallyStreaming.

This should correspond to clang's __arm_streaming_co

[mlir][ArmSME] Add sve streaming compatible attribute (#75222)

Following the same path already used for ArmStreaming and
ArmLocallyStreaming.

This should correspond to clang's __arm_streaming_compatible attribute.

show more ...

[MLIR][LLVM] Support nameless and scopeless global constants (#75307)

This commit ensures that we model DI information for global constants
correctly. These constructs can lack scopes, names, and l

[MLIR][LLVM] Support nameless and scopeless global constants (#75307)

This commit ensures that we model DI information for global constants
correctly. These constructs can lack scopes, names, and linkage names,
so these parameters were made optional for the DIGlobalVariable
attribute.

show more ...

[mlir][llvm] Add llvm.target_features features attribute (#71510)

This patch adds a target_features (TargetFeaturesAttr) to the LLVM
dialect to allow setting and querying the features in use on a f

[mlir][llvm] Add llvm.target_features features attribute (#71510)

This patch adds a target_features (TargetFeaturesAttr) to the LLVM
dialect to allow setting and querying the features in use on a function.

The motivation for this comes from the Arm SME dialect where we would
like a convenient way to check what variants of an operation are
available based on the CPU features.

Intended usage:

The target_features attribute is populated manually or by a pass:

```mlir
func.func @example() attributes {
target_features = #llvm.target_features<["+sme", "+sve", "+sme-f64f64"]>
} {
// ...
}
```

Then within a later rewrite the attribute can be checked, and used to
make lowering decisions.

```c++
// Finds the "target_features" attribute on the parent
// FunctionOpInterface.
auto targetFeatures = LLVM::TargetFeaturesAttr::featuresAt(op);

// Check a feature.
// Returns false if targetFeatures is null or the feature is not in
// the list.
if (!targetFeatures.contains("+sme-f64f64"))
return failure();
```

For now, this is rather simple just checks if the exact feature is in
the list, though it could be possible to extend with implied features
using information from LLVM.

show more ...

[MLIR] Add support for frame pointers in MLIR (#72145)

Add support for frame pointers in MLIR.

---------

Co-authored-by: Markus Böck <markus.boeck02@gmail.com>
Co-authored-by: Christian Ulmann <ch

[MLIR] Add support for frame pointers in MLIR (#72145)

Add support for frame pointers in MLIR.

---------

Co-authored-by: Markus Böck <markus.boeck02@gmail.com>
Co-authored-by: Christian Ulmann <christianulmann@gmail.com>

show more ...

[mlir] Add support for DIGlobalVariable and DIGlobalVariableExpression (#73367)

This PR introduces DIGlobalVariableAttr and
DIGlobalVariableExpressionAttr so that ModuleTranslation can emit the
re

[mlir] Add support for DIGlobalVariable and DIGlobalVariableExpression (#73367)

This PR introduces DIGlobalVariableAttr and
DIGlobalVariableExpressionAttr so that ModuleTranslation can emit the
required metadata needed for debug information about global variable.
The translator implementation for debug metadata needed to be refactored
in order to allow translation of nodes based on MDNode
(DIGlobalVariableExpressionAttr and DIExpression) in addition to
DINode-based nodes.

A DIGlobalVariableExpressionAttr can now be passed to the GlobalOp
operation directly and ModuleTranslation will create the respective
DIGlobalVariable and DIGlobalVariableExpression nodes. The compile unit
that DIGlobalVariable is expected to be configured with will be updated
with the created DIGlobalVariableExpression.

show more ...

[mlir] do not inject malloc/free in to-LLVM translation (#73224)

In the early days of MLIR-to-LLVM IR translation, it had to forcefully
inject declarations of `malloc` and `free` functions as then-

[mlir] do not inject malloc/free in to-LLVM translation (#73224)

In the early days of MLIR-to-LLVM IR translation, it had to forcefully
inject declarations of `malloc` and `free` functions as then-standard
(now `memref`) dialect ops were unconditionally lowering to libc calls.
This is no longer the case. Even when they do lower to libc calls, the
signatures of those methods are injected at lowering since calls must
target declared functions in valid IR. Don't inject those declarations
anymore.

show more ...

[mlir][LLVM] Support `immargs` in LLVM_IntrOpBase intrinsics (#73013)

This extends `LLVM_IntrOpBase` so that it can be passed a list of
`immArgPositions` and a list (of the same length) of `immArgA

[mlir][LLVM] Support `immargs` in LLVM_IntrOpBase intrinsics (#73013)

This extends `LLVM_IntrOpBase` so that it can be passed a list of
`immArgPositions` and a list (of the same length) of `immArgAttrNames`.
`immArgPositions` contains the positions of `immargs` on the LLVM IR
intrinsic, and `immArgAttrNames` maps those to a corresponding MLIR
attribute.

This allows modeling LLVM `immargs` as MLIR attributes, which is the
closest match semantically (and had already been done manually for the
LLVM dialect intrinsics).

This has two upsides:
* It's slightly easier to implement intrinsics with immargs now
(especially if they make use of other features, such as overloads)
* It clearly defines that `immargs` should map to attributes, before
there was no mention of `immargs` in LLVMOpBase.td, so implementing them
was unclear

This works with other features of the `LLVM_IntrOpBase`, so `immargs`
can be marked as overloaded too (which is used in some intrinsics).

As part of this patch (and to test correctness) existing intrinsics have
been updated to use these new parameters.

This also uncovered a few issues with the
`llvm.intr.vector.insert/extract` intrinsics. First, the argument order
for insert did not match the LLVM intrinsic, and secondly, both were
missing a mlirBuilder (so failed to import from LLVM IR). This is
corrected with this patch (and a test case added).

show more ...

[mlir] use TypeSize and uint64_t in DataLayout (#72874)

Data layout queries may be issued for types whose size exceeds the range
of 32-bit integer as well as for types that don't have a size known

[mlir] use TypeSize and uint64_t in DataLayout (#72874)

Data layout queries may be issued for types whose size exceeds the range
of 32-bit integer as well as for types that don't have a size known at
compile time, such as scalable vectors. Use best practices from LLVM IR
and adopt `llvm::TypeSize` for size-related queries and `uint64_t` for
alignment-related queries.

See #72678.

show more ...

[mlir][ArmSME] Make use of backend function attributes for enabling ZA storage (#71044)

Previously, we were inserting za.enable/disable intrinsics for functions
with the "arm_za" attribute (at the

[mlir][ArmSME] Make use of backend function attributes for enabling ZA storage (#71044)

Previously, we were inserting za.enable/disable intrinsics for functions
with the "arm_za" attribute (at the MLIR level), rather than using the
backend attributes. This was done to avoid a dependency on the SME ABI
functions from compiler-rt (which have only recently been implemented).

Doing things this way did have correctness issues, for example, calling
a streaming-mode function from another streaming-mode function (both
with ZA enabled) would lead to ZA being disabled after returning to the
caller (where it should still be enabled). Fixing issues like this would
require re-doing the ABI work already done in the backend within MLIR.

Instead, this patch switches to use the "arm_new_za" (backend) attribute
for enabling ZA for an MLIR function. For the integration tests, this
requires some way of linking the SME ABI functions. This is done via the
`%arm_sme_abi_shlib` lit substitution. By default, this expands to a
stub implementation of the SME ABI functions, but this can be overridden
by providing the `ARM_SME_ABI_ROUTINES_SHLIB` CMake cache variable
(pointing it at an alternative implementation). For now, the ArmSME
integration tests pass with just stubs, as we don't make use of nested
ZA-enabled calls.

A future patch may add an option to compiler-rt to build the SME
builtins into a standalone shared library to allow easily
building/testing with the actual implementation.

show more ...

[NFC] Remove Type::getInt8PtrTy (#71029)

Replace this with PointerType::getUnqual().
Followup to the opaque pointer transition. Fixes an in-code TODO item.

Reland: [MLIR][Transforms] Fix Mem2Reg removal order to respect dominance (#68877)

This commit fixes a bug in the Mem2Reg operation erasure order.
Replacing the use-def based topological order with

Reland: [MLIR][Transforms] Fix Mem2Reg removal order to respect dominance (#68877)

This commit fixes a bug in the Mem2Reg operation erasure order.
Replacing the use-def based topological order with a dominance-based
weak order ensures that no operation is removed before all its uses have
been replaced. The order relation uses the topological order of blocks
and block internal ordering to determine a deterministic operation
order.

Additionally, the reliance on the `DenseMap` key order was eliminated by
switching to a `MapVector`, that gives a deterministic iteration order.

Example:

```
%ptr = alloca ...
...
%val0 = %load %ptr ... // LOAD0
store %val0 %ptr ...
%val1 = load %ptr ... // LOAD1
````

When promoting the slot backing %ptr, it can happen that the LOAD0 was
cleaned before LOAD1. This results in all uses of LOAD0 being replaced
by its reaching definition, before LOAD1's result is replaced by LOAD0's
result. The subsequent erasure of LOAD0 can thus not succeed, as it has
remaining usages.

show more ...

Add support for MLIR to llvm vscale attribute (#67012)

The vscale_range is used for scalabale vector functionality in Arm
Scalable Vector Extension to select the size of vector operation (and I
th

Add support for MLIR to llvm vscale attribute (#67012)

The vscale_range is used for scalabale vector functionality in Arm
Scalable Vector Extension to select the size of vector operation (and I
thnk RISCV has something similar).

This patch adds the base support for the vscale_range attribute to the
LLVM::FuncOp, and the marshalling for translation to LLVM-IR and import
from LLVM-IR to LLVM dialect.

This attribute is intended to be used at higher level MLIR, specified
either by command-line options to the compiler or using compiler
directives (e.g. pragmas or function attributes in the source code) to
indicate the desired range.

show more ...

[mlir][llvm] Use zeroinitializer for TargetExtType (#66510)

Use the recently introduced llvm.mlir.zero operation for values with
LLVM target extension type. Replaces the previous workaround that use

[mlir][llvm] Use zeroinitializer for TargetExtType (#66510)

Use the recently introduced llvm.mlir.zero operation for values with
LLVM target extension type. Replaces the previous workaround that uses a
single zero-valued integer attribute constant operation.

Signed-off-by: Lukas Sommer <lukas.sommer@codeplay.com>

show more ...

[OpenMP][Flang][MLIR] Lowering of requires directive from MLIR to LLVM IR

Default atomic ordering information is processed in the OpenMP dialect
to LLVM IR lowering stage at every spot where an oper

[OpenMP][Flang][MLIR] Lowering of requires directive from MLIR to LLVM IR

Default atomic ordering information is processed in the OpenMP dialect
to LLVM IR lowering stage at every spot where an operation can be
affected by it. The rest of clauses are stored globally in the
OpenMPIRBuilderConfig object before starting that lowering stage, so
that the OMPIRBuilder can conditionally modify code generation
depending on these. At the end of the process, the omp.requires
attribute is itself lowered into a global constructor that passes these
clauses as flags to the OpenMP runtime.

Depends on D147217, D147218 and D158278.

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

show more ...

[OpenMP][OMPIRBuilder] OpenMPIRBuilder support for requires directive

This patch updates the `OpenMPIRBuilderConfig` structure to hold all
available 'requires' clauses, and it replicates part of the

[OpenMP][OMPIRBuilder] OpenMPIRBuilder support for requires directive

This patch updates the `OpenMPIRBuilderConfig` structure to hold all
available 'requires' clauses, and it replicates part of the code
generation for the 'requires' registration function from clang in the
`OMPIRBuilder`, to be used with flang.

Porting the rest of features of the clang implementation to the IRBuilder
and sharing it between clang and flang remains for a future patch, due to the
complexity of the logic selecting the attributes of the generated
registration function.

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

show more ...

Update some uses of `getAttr()` to be explicit about Inherent vs Discardable (NFC)

Revert "Revert "[MLIR] Move builtin.module LLVM IR translation to before nested operations""

This reverts commit 823151f0cfc8f031bcecb15c8246b5649e87b31a.

Revert "[MLIR] Move builtin.module LLVM IR translation to before nested operations"

This reverts commit 0b8c636211b89ba721f060d30290e8a1992879b7.

[MLIR] Move builtin.module LLVM IR translation to before nested operations

This patch moves the call for translating an MLIR module to LLVM IR to the
beginning of the translation process. This enabl

[MLIR] Move builtin.module LLVM IR translation to before nested operations

This patch moves the call for translating an MLIR module to LLVM IR to the
beginning of the translation process. This enables the use of dialect
attributes attached to `builtin.module` operations and the `amendOperation()`
flow to initialize dialect-specific global configuration before translating
the contents of the module.

Currently, this patch does not impact the generated IR on its own. Testing
infrastructure to allow translating the Test dialect to LLVM IR is added, so
that it can be checked that the current behavior is not broken in the future.

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

show more ...