Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
1c067a51 |
| 08-Jan-2025 |
William Moses <gh@wsmoses.com> |
[MLIR] Enable import of non self referential alias scopes (#121987)
Fixes #121965.
---------
Co-authored-by: Christian Ulmann <christianulmann@gmail.com>
Co-authored-by: Alex Zinenko <git@ozi
[MLIR] Enable import of non self referential alias scopes (#121987)
Fixes #121965.
---------
Co-authored-by: Christian Ulmann <christianulmann@gmail.com>
Co-authored-by: Alex Zinenko <git@ozinenko.com>
show more ...
|
Revision tags: llvmorg-19.1.6, llvmorg-19.1.5 |
|
#
92a15dd7 |
| 27-Nov-2024 |
Krzysztof Drewniak <Krzysztof.Drewniak@amd.com> |
[mlir][LLVM] Plumb range attributes on parameters and results through (#117801)
We've had the ability to define LLVM's `range` attribute through
#llvm.constant_range for some time, and have used t
[mlir][LLVM] Plumb range attributes on parameters and results through (#117801)
We've had the ability to define LLVM's `range` attribute through
#llvm.constant_range for some time, and have used this for some GPU
intrinsics. This commit allows using `llvm.range` as a parameter or
result attribute on function declarations and definitions.
show more ...
|
Revision tags: llvmorg-19.1.4 |
|
#
40afff7b |
| 15-Nov-2024 |
lfrenot <leon.frenot@ens-lyon.fr> |
[mlir][LLVM] Add disjoint flag (#115855)
The implementation is mostly based on the one existing for the exact
flag.
disjoint means that for each bit, that bit is zero in at least one of
the inp
[mlir][LLVM] Add disjoint flag (#115855)
The implementation is mostly based on the one existing for the exact
flag.
disjoint means that for each bit, that bit is zero in at least one of
the inputs. This allows the Or to be treated as an Add since no carry
can occur from any bit. If the disjoint keyword is present, the result
value of the or is a [poison
value](https://llvm.org/docs/LangRef.html#poisonvalues) if both inputs
have a one in the same bit position. For vectors, only the element
containing the bit is poison.
show more ...
|
Revision tags: llvmorg-19.1.3 |
|
#
1dfb104e |
| 16-Oct-2024 |
Sirui Mu <msrlancern@gmail.com> |
[mlir][LLVMIR] Add operand bundle support for llvm.intr.assume (#112143)
This patch adds operand bundle support for `llvm.intr.assume`.
This patch actually contains two parts:
- `llvm.intr.assume`
[mlir][LLVMIR] Add operand bundle support for llvm.intr.assume (#112143)
This patch adds operand bundle support for `llvm.intr.assume`.
This patch actually contains two parts:
- `llvm.intr.assume` now accepts operand bundle related attributes and operands. `llvm.intr.assume` does not take constraint on the operand bundles, but obviously only a few set of operand bundles are meaningful. I plan to add some of those (e.g. `aligned` and `separate_storage` are what interest me but other people may be interested in other operand bundles as well) in future patches.
- The definitions of `llvm.call`, `llvm.invoke`, and `llvm.call_intrinsic` actually define `op_bundle_tags` as an operation property. It turns out this approach would introduce some unnecessary burden if applied equally to the intrinsic operations because properties are not available through `Operation *` but we have to operate on `Operation *` during the import/export of intrinsics, so this PR changes it from a property to an array attribute.
This patch relands commit d8fadad07c952c4aea967aefb0900e4e43ad0555.
show more ...
|
#
484c0278 |
| 16-Oct-2024 |
Sirui Mu <msrlancern@gmail.com> |
Revert "[mlir][LLVMIR] Add operand bundle support for llvm.intr.assume (#112143)"
This reverts commit d8fadad07c952c4aea967aefb0900e4e43ad0555.
The commit breaks the following CI builds: - ppc64le-
Revert "[mlir][LLVMIR] Add operand bundle support for llvm.intr.assume (#112143)"
This reverts commit d8fadad07c952c4aea967aefb0900e4e43ad0555.
The commit breaks the following CI builds: - ppc64le-mlir-rhel-clang: https://lab.llvm.org/buildbot/#/builders/129/builds/7685 - ppc64le-flang-rhel-clang: https://lab.llvm.org/buildbot/#/builders/157/builds/10338
show more ...
|
#
d8fadad0 |
| 16-Oct-2024 |
Sirui Mu <msrlancern@gmail.com> |
[mlir][LLVMIR] Add operand bundle support for llvm.intr.assume (#112143)
This patch adds operand bundle support for `llvm.intr.assume`.
This patch actually contains two parts:
- `llvm.intr.ass
[mlir][LLVMIR] Add operand bundle support for llvm.intr.assume (#112143)
This patch adds operand bundle support for `llvm.intr.assume`.
This patch actually contains two parts:
- `llvm.intr.assume` now accepts operand bundle related attributes and
operands. `llvm.intr.assume` does not take constraint on the operand
bundles, but obviously only a few set of operand bundles are meaningful.
I plan to add some of those (e.g. `aligned` and `separate_storage` are
what interest me but other people may be interested in other operand
bundles as well) in future patches.
- The definitions of `llvm.call`, `llvm.invoke`, and
`llvm.call_intrinsic` actually define `op_bundle_tags` as an operation
property. It turns out this approach would introduce some unnecessary
burden if applied equally to the intrinsic operations because properties
are not available through `Operation *` but we have to operate on
`Operation *` during the import/export of intrinsics, so this PR changes
it from a property to an array attribute.
show more ...
|
Revision tags: llvmorg-19.1.2 |
|
#
839344f0 |
| 14-Oct-2024 |
Tarun Prabhu <tarun@lanl.gov> |
[clang][flang][mlir] Reapply "Support -frecord-command-line option (#102975)"
The underlying issue was caused by a file included in two different
places which resulted in duplicate definition error
[clang][flang][mlir] Reapply "Support -frecord-command-line option (#102975)"
The underlying issue was caused by a file included in two different
places which resulted in duplicate definition errors when linking
individual shared libraries. This was fixed in c3201ddaeac02a2c86a38b
[#109874].
show more ...
|
#
cd12ffb6 |
| 13-Oct-2024 |
Abid Qadeer <haqadeer@amd.com> |
[mlir][debug] Allow multiple DIGlobalVariableExpression on globals. (#111981)
Currently, we allow only one DIGlobalVariableExpressionAttr per global.
It is especially evident in import where we pic
[mlir][debug] Allow multiple DIGlobalVariableExpression on globals. (#111981)
Currently, we allow only one DIGlobalVariableExpressionAttr per global.
It is especially evident in import where we pick the first from the list
and ignore the rest. In contrast, LLVM allows multiple
DIGlobalVariableExpression to be attached to the global. They are needed
for correct working of things like DICommonBlock. This PR removes this
restriction in mlir. Changes are mostly mechanical. One thing on which I
went a bit back and forth was the representation inside GlobalOp. I
would be happy to change if there are better ways to do this.
---------
Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
show more ...
|
#
fa789dff |
| 11-Oct-2024 |
Rahul Joshi <rjoshi@nvidia.com> |
[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)
Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is a
[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)
Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is also in preparation of
adding a new `Intrinsic::getDeclaration` that will have behavior similar
to `Module::getFunction` (i.e, just lookup, no creation).
show more ...
|
#
36c34ec9 |
| 10-Oct-2024 |
Abid Qadeer <haqadeer@amd.com> |
[mlir][debug] Support DICommonBlock. (#111706)
A COMMON block is a named area of memory that holds a collection of
variables. Fortran subprograms may map the COMMON block memory area to a
list of
[mlir][debug] Support DICommonBlock. (#111706)
A COMMON block is a named area of memory that holds a collection of
variables. Fortran subprograms may map the COMMON block memory area to a
list of variables. A common block is represented in LLVM debug by
DICommonBlock.
This PR adds support for this in MLIR. The changes are mostly mechanical
apart from small change to access the DICompileUnit when the scope of
the variable is DICommonBlock.
---------
Co-authored-by: Tobias Gysi <tobias.gysi@nextsilicon.com>
show more ...
|
Revision tags: llvmorg-19.1.1 |
|
#
123e8c73 |
| 22-Sep-2024 |
Youngsuk Kim <youngsuk.kim@hpe.com> |
[mlir] Don't call llvm::raw_string_ostream::flush() (NFC)
Don't call raw_string_ostream::flush(), which is essentially a no-op. As specified in the docs, raw_string_ostream is always unbuffered. ( 6
[mlir] Don't call llvm::raw_string_ostream::flush() (NFC)
Don't call raw_string_ostream::flush(), which is essentially a no-op. As specified in the docs, raw_string_ostream is always unbuffered. ( 65b13610a5226b84889b923bae884ba395ad084d for further reference )
show more ...
|
#
737c414e |
| 20-Sep-2024 |
David Spickett <david.spickett@linaro.org> |
Revert "[clang][flang][mlir] Support -frecord-command-line option (#102975)"
This reverts commit b3533a156da92262eb19429d8c12f53e87f5ccec.
It caused test failures in shared library builds: https://
Revert "[clang][flang][mlir] Support -frecord-command-line option (#102975)"
This reverts commit b3533a156da92262eb19429d8c12f53e87f5ccec.
It caused test failures in shared library builds: https://lab.llvm.org/buildbot/#/builders/80/builds/3854
show more ...
|
#
b3533a15 |
| 20-Sep-2024 |
Tarun Prabhu <tarun@lanl.gov> |
[clang][flang][mlir] Support -frecord-command-line option (#102975)
Add support for the -frecord-command-line option that will produce the
llvm.commandline metadata which will eventually be saved i
[clang][flang][mlir] Support -frecord-command-line option (#102975)
Add support for the -frecord-command-line option that will produce the
llvm.commandline metadata which will eventually be saved in the object
file. This behavior is also supported in clang. Some refactoring of the
code in flang to handle these command line options was carried out. The
corresponding -grecord-command-line option which saves the command line
in the debug information has not yet been enabled for flang.
show more ...
|
Revision tags: llvmorg-19.1.0 |
|
#
80cd2141 |
| 05-Sep-2024 |
Mogball <jeff@modular.com> |
[mlir][llvm] Add `externally_initialized` support to GlobalOp
This maps the `externally_initialized` flag in `llvm::GlobalVariable` to `GlobalOp` and adds exported support.
|
Revision tags: llvmorg-19.1.0-rc4 |
|
#
318b0678 |
| 22-Aug-2024 |
Sirui Mu <msrlancern@gmail.com> |
[mlir][LLVM] Add support for constant struct with multiple fields (#102752)
Currently `mlir.llvm.constant` of structure types restricts that the
structure type effectively represents a complex type
[mlir][LLVM] Add support for constant struct with multiple fields (#102752)
Currently `mlir.llvm.constant` of structure types restricts that the
structure type effectively represents a complex type -- it must have
exactly two fields of the same type and the field type must be either an
integer type or a float type.
This PR relaxes this restriction and it allows the structure type to
have an arbitrary number of fields.
show more ...
|
#
00a1a45a |
| 22-Aug-2024 |
Abid Qadeer <haqadeer@amd.com> |
[mlir][llvmir][debug] Correctly generate location for phi nodes. (#105534)
In
[convertBlockImpl](https://github.com/llvm/llvm-project/blob/87eeed1f0ebe57abffde560c25dd9829dc6038f3/mlir/lib/Target/L
[mlir][llvmir][debug] Correctly generate location for phi nodes. (#105534)
In
[convertBlockImpl](https://github.com/llvm/llvm-project/blob/87eeed1f0ebe57abffde560c25dd9829dc6038f3/mlir/lib/Target/LLVMIR/ModuleTranslation.cpp#L959),
the debug location is set on the builder before the op is processed.
This results in correct location being given to corresponding llvm
instructions. But same is not done when phi nodes are created a few
lines above. This result is phi nodes getting whatever the current debug
location of the builder is. It can be nothing or in worst case a stale
location. Fixed by calling SetCurrentDebugLocation before generating phi
nodes.
show more ...
|
Revision tags: llvmorg-19.1.0-rc3 |
|
#
90aac06c |
| 12-Aug-2024 |
Tarun Prabhu <tarun@lanl.gov> |
[flang][mlir] Add llvm.ident metadata when compiling with flang
This brings the behavior of flang in line with clang which also adds
this metadata unconditionally.
Co-authored-by: Tarun Prabhu <
[flang][mlir] Add llvm.ident metadata when compiling with flang
This brings the behavior of flang in line with clang which also adds
this metadata unconditionally.
Co-authored-by: Tarun Prabhu <tarun.prabhu@gmail.com>
show more ...
|
Revision tags: llvmorg-19.1.0-rc2 |
|
#
6d2bbba1 |
| 02-Aug-2024 |
Victor Perez <victor.perez@codeplay.com> |
[MLIR][LLVM] Attach kernel metadata representation to `llvm.func` (#101314)
Add optional attributes to `llvm.func` representing LLVM so-called
"kernel" metadata:
-
[`vec_type_hint`](https://cla
[MLIR][LLVM] Attach kernel metadata representation to `llvm.func` (#101314)
Add optional attributes to `llvm.func` representing LLVM so-called
"kernel" metadata:
-
[`vec_type_hint`](https://clang.llvm.org/docs/AttributeReference.html#vec-type-hint)
-
[`work_group_size_hint`](https://clang.llvm.org/docs/AttributeReference.html#work-group-size-hint)
-
[`reqd_work_group_size`](https://clang.llvm.org/docs/AttributeReference.html#reqd-work-group-size)
-
[`intel_reqd_sub_group_size`](https://clang.llvm.org/docs/AttributeReference.html#intel-reqd-sub-group-size).
---------
Signed-off-by: Victor Perez <victor.perez@codeplay.com>
show more ...
|
Revision tags: llvmorg-19.1.0-rc1 |
|
#
2eea9d6a |
| 23-Jul-2024 |
Finlay <finlay.marno@codeplay.com> |
[mlir] Rename memory attribute to memory_effects in llvmir dialect (#100108)
This commit renames the memory attribute on operations to "memory_effects" to be in line with the naming LLVM IR is using.
|
Revision tags: llvmorg-20-init |
|
#
aa21ee79 |
| 17-Jul-2024 |
Finlay <finlay.marno@codeplay.com> |
[MLIR] Add attributes no_unwind and will_return to the LLVMIR dialect (#98921)
And testing.
These are being added to be used in the GPU to LLVM SPV pass.
---------
Co-authored-by: Victor Pere
[MLIR] Add attributes no_unwind and will_return to the LLVMIR dialect (#98921)
And testing.
These are being added to be used in the GPU to LLVM SPV pass.
---------
Co-authored-by: Victor Perez <victor.perez@codeplay.com>
show more ...
|
#
f1d3fe7a |
| 16-Jul-2024 |
Alexis Perry-Holby <AlexisPerry@users.noreply.github.com> |
Add basic -mtune support (#98517)
Initial implementation for the -mtune flag in Flang.
This PR is a clean version of PR #96688, which is a re-land of PR #95043
|
#
dab36b28 |
| 11-Jul-2024 |
Abid Qadeer <haqadeer@amd.com> |
[mlir][debug] Allow global with local scope. (#98358)
Currently, only those global variables in debug info are allowed which
have a compile unit or module scope. But global variable with function
[mlir][debug] Allow global with local scope. (#98358)
Currently, only those global variables in debug info are allowed which
have a compile unit or module scope. But global variable with function
scope are used in debug info to represent certain type of variables. One
example will be static local variables in C. Here the variable is
represented as global variable with parent function as its scope. See
the code and debug metadata as generated by clang below. You can see
that scope of `DIGlobalVariable` is `DISubprogram`.
```
int test() {
static int a = 0;
return a++;
}
!0 = !DIGlobalVariableExpression(var: !1...)
!1 = !DIGlobalVariable(name: "a", scope: !2 ...)
!2 = !DISubprogram(name: "test" ...)
!7 = !DICompileUnit(... globals: !8...)
!8 = !{!0}
```
Similar issue exist in fortran where global variable with function scope
are used to represent local variable with save attribute.
This PR will allows such variables during module translation.
show more ...
|
#
ad315ebf |
| 09-Jul-2024 |
Mats Petersson <mats.petersson@arm.com> |
[MLIR][NFC]Fix unusued variable warning. (#97813)
This just changes a dyn_cast to and isa call to check for type, which
avoids getting a warning in clang. The variable `ity` is not used in the
nex
[MLIR][NFC]Fix unusued variable warning. (#97813)
This just changes a dyn_cast to and isa call to check for type, which
avoids getting a warning in clang. The variable `ity` is not used in the
next block.
No functional change.
show more ...
|
#
e5865ec9 |
| 09-Jul-2024 |
runseny <145632023+runseny@users.noreply.github.com> |
[MLIR][LLVM] Add ftz and fuse FP ops related function attribute support (#97812)
Adds `denormal-fp-math-f32`, `denormal-fp-math`, `fp-contract` to
llvmFuncOp attributes.
`denormal-fp-math-f32` a
[MLIR][LLVM] Add ftz and fuse FP ops related function attribute support (#97812)
Adds `denormal-fp-math-f32`, `denormal-fp-math`, `fp-contract` to
llvmFuncOp attributes.
`denormal-fp-math-f32` and `denormal-fp-math` can enable the ftz, that
is , flushing denormal to zero.
`fp-contract` can enable the fma fusion such as `mul + add -> fma`
show more ...
|
#
d6df0187 |
| 05-Jul-2024 |
Finlay <finlay.marno@codeplay.com> |
[MLIR] Add the convergent attribute to LLVM Dialect (#97709)
In order to use the convergent attribute in the GPUToLLVMSPV pass, I've
added the attribute to the LLVM dialect.
Some details on the co
[MLIR] Add the convergent attribute to LLVM Dialect (#97709)
In order to use the convergent attribute in the GPUToLLVMSPV pass, I've
added the attribute to the LLVM dialect.
Some details on the convergent attribute
https://llvm.org/docs/ConvergentOperations.html#convergent-operations
show more ...
|