mlir/LogicalResult: move into llvm (#97309)

This patch is part of a project to move the Presburger library into
LLVM.

Revert "[flang] Add basic -mtune support" (#96678)

Reverts llvm/llvm-project#95043

[flang] Add basic -mtune support (#95043)

This PR adds -mtune as a valid flang flag and passes the information
through to LLVM IR as an attribute on all functions. No specific
architecture optimiz

[flang] Add basic -mtune support (#95043)

This PR adds -mtune as a valid flang flag and passes the information
through to LLVM IR as an attribute on all functions. No specific
architecture optimizations are added at this time.

show more ...

[MLIR][DebugInfo] Set debug info format in MLIR->IR translation (#95329)

MLIR's LLVM dialect does not internally support debug records, only
converting to/from debug intrinsics. To smooth the trans

[MLIR][DebugInfo] Set debug info format in MLIR->IR translation (#95329)

MLIR's LLVM dialect does not internally support debug records, only
converting to/from debug intrinsics. To smooth the transition from
intrinsics to records, there is a step prior to IR->MLIR translation
that switches the IR module to intrinsic-form; this patch adds the
equivalent conversion to record-form at MLIR->IR translation.

This is a partial reapply of
https://github.com/llvm/llvm-project/pull/95098 which can be landed once
the flang frontend has been updated by
https://github.com/llvm/llvm-project/pull/95306. This is the counterpart
to the earlier patch https://github.com/llvm/llvm-project/pull/89735
which handled the IR->MLIR conversion.

show more ...

[MLIR][LLVM] Promote noinline/alwaysinline/optnone out of passthrough (#95110)

The `noinline`, `alwaysinline`, and `optnone` function attributes are
already being used in MLIR code for the LLVM inl

[MLIR][LLVM] Promote noinline/alwaysinline/optnone out of passthrough (#95110)

The `noinline`, `alwaysinline`, and `optnone` function attributes are
already being used in MLIR code for the LLVM inlining interface and in
some SPIR-V lowering, despite residing in the passthrough dictionary,
which is intended as exactly that -- a pass through MLIR -- and not to
model any actual semantics being handled in MLIR itself.

Promote the `noinline`, `alwaysinline`, and `optnone` attributes out of
the passthrough dictionary on `llvm.func` into first class unit
attributes, updating the import and export accordingly.

Add a verifier to `llvm.func` that checks that these attributes are not
set in an incompatible way according to the LLVM specification.

Update the LLVM dialect inlining interface to use the first class
attributes to check whether inlining is possible.

show more ...

Revert#2 "[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)"

Also reverts "[MLIR][Flang][DebugInfo] Convert debug format in MLIR translators"

The patch above introduce

Revert#2 "[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)"

Also reverts "[MLIR][Flang][DebugInfo] Convert debug format in MLIR translators"

The patch above introduces behaviour controlled by an LLVM flag into the
Flang driver, which is incorrect behaviour.

This reverts commits:
3cc2710e0dd53bb82742904fa13014018a1137ed.
460408f78b30720950040e336f7b566aa7203269.

show more ...

Reapply "[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)"

Reapplies the original patch with some additional conversion layers added
to the MLIR translator, to ensure

Reapply "[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)"

Reapplies the original patch with some additional conversion layers added
to the MLIR translator, to ensure that we don't write the new debug info
format unless WriteNewDbgInfoFormat is set.

This reverts commit 8c5d9c79b96ed8297b381e00d3a706a432cd6c9d.

show more ...

Revert "[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)"

Reverted due to failure on buildbot due to missing use of the
WriteNewDbgInfoFormat flag in MLIR.

This rever

Revert "[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)"

Reverted due to failure on buildbot due to missing use of the
WriteNewDbgInfoFormat flag in MLIR.

This reverts commit ca920bb6285e9995f5a202d040af79363e98ab28.

show more ...

[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)

MLIR's LLVM dialect does not internally support debug records, only
converting to/from debug intrinsics. To smooth th

[MLIR][Flang][DebugInfo] Set debug info format in MLIR->IR translation (#95098)

MLIR's LLVM dialect does not internally support debug records, only
converting to/from debug intrinsics. To smooth the transition from
intrinsics to records, there is a step prior to IR->MLIR translation
that switches the IR module to intrinsic-form; this patch adds the
equivalent conversion to record-form at MLIR->IR translation, and also
modifies the flang front end to use the WriteNewDbgInfoFormat flag when
it is emitting LLVM IR.

show more ...

[MLIR][ModuleTranslation] Add disableVerification parameter (NFC) (#94445)

This commit adds a boolean parameter that allows downstream users to
disable the verification when translating an MLIR mod

[MLIR][ModuleTranslation] Add disableVerification parameter (NFC) (#94445)

This commit adds a boolean parameter that allows downstream users to
disable the verification when translating an MLIR module to LLVM IR.
This is helpful for debugging broken LLVM IR modules post translation.

show more ...

[mlir] Align num elements type to LLVM ArrayType (#93230)

MLIR LLMArrayType is using `unsigned` for the number of elements while
LLVM ArrayType is using `uint64_t`
https://github.com/llvm/llvm-pro

[mlir] Align num elements type to LLVM ArrayType (#93230)

MLIR LLMArrayType is using `unsigned` for the number of elements while
LLVM ArrayType is using `uint64_t`
https://github.com/llvm/llvm-project/blob/4ae896fe979b7db501cabde4b6b3504478958682/llvm/include/llvm/IR/DerivedTypes.h#L377

This leads to silent truncation when we use it for globals in flang.

```
program test
integer(8), parameter :: large = 2**30
real, dimension(large) :: bigarray
common /c/ bigarray
bigarray(999) = 666
end
```

The above program would result in a segfault since the global would be
of size 0 because of the silent truncation.

```
fir.global common @c_(dense<0> : vector<4294967296xi8>) : !fir.array<4294967296xi8>
```
became
```
llvm.mlir.global common @c_(dense<0> : vector<4294967296xi8>) {addr_space = 0 : i32} : !llvm.array<0 x i8>
```

This patch updates the definition of MLIR ArrayType to take `uint64_t`
as argument of the number of elements to be compatible with LLVM.

show more ...

[MLIR][Analysis] Consolidate topological sort utilities (#92563)

This PR attempts to consolidate the different topological sort utilities
into one place. It adds them to the analysis folder becaus

[MLIR][Analysis] Consolidate topological sort utilities (#92563)

This PR attempts to consolidate the different topological sort utilities
into one place. It adds them to the analysis folder because the
`SliceAnalysis` uses some of these.

There are now two different sorting strategies:
1. Sort only according to SSA use-def chains
2. Sort while taking regions into account. This requires a much more
elaborate traversal and cannot be applied on graph regions that easily.

This additionally reimplements the region aware topological sorting
because the previous implementation had an exponential space complexity.

I'm open to suggestions on how to combine this further or how to fuse
the test passes.

show more ...

[MLIR][Transforms] Correct block sorting utils name (NFC) (#92558)

This commit renames the name of the block sorting utility function to
`getBlocksSortedByDominance`. A topological order is not def

[MLIR][Transforms] Correct block sorting utils name (NFC) (#92558)

This commit renames the name of the block sorting utility function to
`getBlocksSortedByDominance`. A topological order is not defined on a
general directed graph, so the previous name did not make sense.

show more ...

[mlir][flang] Improve handling of fortran module variables. (#91604)

Currently, only those global variables which are at compile unit scope
are added to the 'globals' list of the DICompileUnit. Thi

[mlir][flang] Improve handling of fortran module variables. (#91604)

Currently, only those global variables which are at compile unit scope
are added to the 'globals' list of the DICompileUnit. This does not work
for languages which support modules (e.g. Fortran) where hierarchy
can be
variable -> module -> compile unit.

To fix this, if a variable scope points to a module, we walk one level
up and see if module is in the compile unit scope.

This was initially part of #91582 which adds debug information for
Fortran module variables. @kiranchandramohan pointed out that MLIR
changes should go in separate PRs.

show more ...

[MLIR][LLVM] Add `llvm.experimental.constrained.fptrunc` operation (#86260)

Add operation mapping to the LLVM
`llvm.experimental.constrained.fptrunc.*` intrinsic.

The new operation implements th

[MLIR][LLVM] Add `llvm.experimental.constrained.fptrunc` operation (#86260)

Add operation mapping to the LLVM
`llvm.experimental.constrained.fptrunc.*` intrinsic.

The new operation implements the new
`LLVM::FPExceptionBehaviorOpInterface` and
`LLVM::RoundingModeOpInterface` interfaces.

---------

Signed-off-by: Victor Perez <victor.perez@codeplay.com>

show more ...

[MLIR] Add index bitwidth to the DataLayout (#85927)

When importing from LLVM IR the data layout of all pointer types
contains an index bitwidth that should be used for index computations.
This re

[MLIR] Add index bitwidth to the DataLayout (#85927)

When importing from LLVM IR the data layout of all pointer types
contains an index bitwidth that should be used for index computations.
This revision adds a getter to the DataLayout that provides access to
the already stored bitwidth. The function returns an optional since only
pointer-like types have an index bitwidth. Querying the bitwidth of a
non-pointer type returns std::nullopt.

The new function works for the built-in Index type and, using a type
interface, for the LLVMPointerType.

show more ...

[mlir][LLVM] erase call mappings in forgetMapping() (#84955)

It looks like the mappings for call instructions were forgotten here.
This fixes a bug in OpenMP when in-lining a region containing call

[mlir][LLVM] erase call mappings in forgetMapping() (#84955)

It looks like the mappings for call instructions were forgotten here.
This fixes a bug in OpenMP when in-lining a region containing call
operations multiple times.

OpenMP array reductions 4/6
Previous PR: https://github.com/llvm/llvm-project/pull/84954
Next PR: https://github.com/llvm/llvm-project/pull/84957

show more ...

[mlir][llvm] Fix access group translation (#83257)

This commit fixes the translation of access group metadata to LLVM IR.
Previously, it did not use a temporary metadata node to model the
placehol

[mlir][llvm] Fix access group translation (#83257)

This commit fixes the translation of access group metadata to LLVM IR.
Previously, it did not use a temporary metadata node to model the
placeholder of the self-referencing access group nodes. This is
dangerous since, the translation may produce a metadata list with a null
entry that is later on changed changed with a self reference. At the
same time, for example the debug info translation may create the same
uniqued node, which after setting the self-reference the suddenly
references the access group metadata. The commit avoids such breakages.

show more ...

[mlir] Fix -Wunused-but-set-variable in ModuleTranslation.cpp (NFC)

mlir/lib/Target/LLVMIR/ModuleTranslation.cpp:1050:11:
error: variable 'numConstantsHit' set but not used [-Werror,-Wunused-but-set

[mlir] Fix -Wunused-but-set-variable in ModuleTranslation.cpp (NFC)

mlir/lib/Target/LLVMIR/ModuleTranslation.cpp:1050:11:
error: variable 'numConstantsHit' set but not used [-Werror,-Wunused-but-set-variable]
int numConstantsHit = 0;
^
mlir/lib/Target/LLVMIR/ModuleTranslation.cpp:1051:11:
error: variable 'numConstantsErased' set but not used [-Werror,-Wunused-but-set-variable]
int numConstantsErased = 0;
^
2 errors generated.

show more ...

[MLIR][LLVM] Fix memory explosion when converting global variable bodies in ModuleTranslation (#82708)

There is memory explosion when converting the body or initializer region
of a large global var

[MLIR][LLVM] Fix memory explosion when converting global variable bodies in ModuleTranslation (#82708)

There is memory explosion when converting the body or initializer region
of a large global variable, e.g. a constant array.

For example, when translating a constant array of 100000 strings:

llvm.mlir.global internal constant @cats_strings() {addr_space = 0 :
i32, alignment = 16 : i64} : !llvm.array<100000 x ptr<i8>> {
%0 = llvm.mlir.undef : !llvm.array<100000 x ptr<i8>>
%1 = llvm.mlir.addressof @om_1 : !llvm.ptr<array<1 x i8>>
%2 = llvm.getelementptr %1[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
%3 = llvm.insertvalue %2, %0[0] : !llvm.array<100000 x ptr<i8>>
%4 = llvm.mlir.addressof @om_2 : !llvm.ptr<array<1 x i8>>
%5 = llvm.getelementptr %4[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
%6 = llvm.insertvalue %5, %3[1] : !llvm.array<100000 x ptr<i8>>
%7 = llvm.mlir.addressof @om_3 : !llvm.ptr<array<1 x i8>>
%8 = llvm.getelementptr %7[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
%9 = llvm.insertvalue %8, %6[2] : !llvm.array<100000 x ptr<i8>>
%10 = llvm.mlir.addressof @om_4 : !llvm.ptr<array<1 x i8>>
%11 = llvm.getelementptr %10[0, 0] : (!llvm.ptr<array<1 x i8>>) ->
!llvm.ptr<i8>
%12 = llvm.insertvalue %11, %9[3] : !llvm.array<100000 x ptr<i8>>

... (ignore the remaining part)
}

where @om_1, @om_2, ... are string global constants.

Each time an operation is converted to LLVM, a new constant is created.
When it comes to llvm.insertvalue, a new constant array of 100000
elements is created and the old constant array (input) is not destroyed.
This causes memory explosion. We observed that, on a system with 128 GB
memory, the translation of 100000 elements got killed due to using up
all the memory. On a system with 64 GB, 65536 elements was enough to
cause the translation killed.

There is a previous patch (https://reviews.llvm.org/D148487) which fix
this issue but was reverted for
https://github.com/llvm/llvm-project/issues/62802

The old patch checks generated constants and destroyed them if there is
no use. But the check of use for the constant is too early, which cause
the constant be removed before use.


This new patch added a map was added a map to save expected use count
for a constant. Then decrease when reach each use.
And only erase the constant when the use count reach to zero

With new patch, the repro in
https://github.com/llvm/llvm-project/issues/62802 finished correctly.

show more ...

[mlir][nvvm]Add support for grid_constant attribute on LLVM function arguments (#78228)

Add support for attribute nvvm.grid_constant on LLVM function arguments.
The attribute can be attached only t

[mlir][nvvm]Add support for grid_constant attribute on LLVM function arguments (#78228)

Add support for attribute nvvm.grid_constant on LLVM function arguments.
The attribute can be attached only to arguments of type llvm.ptr that
have llvm.byval attribute.
Generate LLVM metadata for functions with nvvm.grid_constant arguments.
The metadata node is a list of integers, where each integer n denotes
that the nth parameter has the
grid_constant annotation (numbering from 1). The generated metadata node
will be handled by NVVM compiler. See
https://docs.nvidia.com/cuda/nvvm-ir-spec/index.html#supported-properties
for documentation on grid_constant property.

This patch also adds convertParameterAttr to
LLVMTranslationDialectInterface for supporting the translation of
derived dialect attributes on function parameters 

show more ...

[AArch64] Replace LLVM IR function attributes for PSTATE.ZA. (#79166)

Since https://github.com/ARM-software/acle/pull/276 the ACLE
defines attributes to better describe the use of a given SME state

[AArch64] Replace LLVM IR function attributes for PSTATE.ZA. (#79166)

Since https://github.com/ARM-software/acle/pull/276 the ACLE
defines attributes to better describe the use of a given SME state.

Previously the attributes merely described the possibility of it being
'shared' or 'preserved', whereas the new attributes have more semantics
and also describe how the data flows through the program.

For ZT0 we already had to add new LLVM IR attributes:
* aarch64_new_zt0
* aarch64_in_zt0
* aarch64_out_zt0
* aarch64_inout_zt0
* aarch64_preserves_zt0

We have now done the same for ZA, such that we add:
* aarch64_new_za (previously `aarch64_pstate_za_new`)
* aarch64_in_za (more specific variation of `aarch64_pstate_za_shared`)
* aarch64_out_za (more specific variation of `aarch64_pstate_za_shared`)
* aarch64_inout_za (more specific variation of
`aarch64_pstate_za_shared`)
* aarch64_preserves_za (previously `aarch64_pstate_za_shared,
aarch64_pstate_za_preserved`)

This explicitly removes 'pstate' from the name, because with SME2 and
the new ACLE attributes there is a difference between "sharing ZA"
(sharing
the ZA matrix register with the caller) and "sharing PSTATE.ZA" (sharing
either the ZA or ZT0 register, both part of PSTATE.ZA with the caller).

show more ...

[MLIR][LLVM] Add fast-math related function attribute support (#79812)

Adds unsafe-fp-math, no-infs-fp-math, no-nans-fp-math,
approx-func-fp-math, and no-signed-zeros-fp-math function attributes.

[MLIR][LLVM] Add fast-math related function attribute support (#79812)

Adds unsafe-fp-math, no-infs-fp-math, no-nans-fp-math,
approx-func-fp-math, and no-signed-zeros-fp-math function attributes.

This allows code generators using the LLVMIR dialect to match the
codegen of Clang.

show more ...

[mlir][Target] Teach dense_resource conversion to LLVMIR Target (#78958)

This patch adds support for translating dense_resource attributes to
LLVMIR Target.
The support added is similar to how Dense

[mlir][Target] Teach dense_resource conversion to LLVMIR Target (#78958)

This patch adds support for translating dense_resource attributes to
LLVMIR Target.
The support added is similar to how DenseElementsAttr is handled, except
we
don't need to handle splats.

Another possible way of doing this is adding iteration on
dense_resource, but that is
non-trivial as DenseResourceAttr is not meant to be something you should
directly
access. It has subclasses which you are supposed to use to iterate on
it.

show more ...

[MLIR][LLVM] Add explicit target_cpu attribute to llvm.func (#78287)

This patch adds the target_cpu attribute to llvm.func MLIR operations
and updates the translation to/from LLVM IR to match "targ

[MLIR][LLVM] Add explicit target_cpu attribute to llvm.func (#78287)

This patch adds the target_cpu attribute to llvm.func MLIR operations
and updates the translation to/from LLVM IR to match "target-cpu"
function attributes.

show more ...