Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
#
15e1e3b2 |
| 14-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang] Read the extra field from the in box when doing reboxing (#102992)
Updated version of #102686. The issue was that in some rebox case the
addendum presence flag should be updated and not alw
[flang] Read the extra field from the in box when doing reboxing (#102992)
Updated version of #102686. The issue was that in some rebox case the
addendum presence flag should be updated and not always taken from the
"from" box. This is the case when reboxing a fir.class to a fir.box that
doesn't require an addendum for example.
Open a new review since there is a bit of additional code in the CodeGen
part.
show more ...
|
#
8fc9b4ef |
| 12-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
Revert "[flang] Read the extra field from the in box when doing reboxing" (#102931)
Reverts llvm/llvm-project#102686 as it might be the source of buildbot
failures https://lab.llvm.org/buildbot/#/b
Revert "[flang] Read the extra field from the in box when doing reboxing" (#102931)
Reverts llvm/llvm-project#102686 as it might be the source of buildbot
failures https://lab.llvm.org/buildbot/#/builders/143/builds/1392.
show more ...
|
#
dab7e3c3 |
| 12-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang] Read the extra field from the in box when doing reboxing (#102686)
The extra field in the descriptor carries multiple information and
cannot be deducted anymore when doing a reboxing. This
[flang] Read the extra field from the in box when doing reboxing (#102686)
The extra field in the descriptor carries multiple information and
cannot be deducted anymore when doing a reboxing. This patch updates the
codegen to retrieve the extra field value from the inboc and set it in
the new box.
show more ...
|
#
ce2a3d90 |
| 06-Aug-2024 |
Kelvin Li <kkwli@users.noreply.github.com> |
[flang] Match the type of the element size in the box in getValueFromBox (#100512)
Currently, `%17 = fir.box_elesize %16 :
(!fir.class<!fir.ptr<!fir.type<_QFTt{a:i32,b:i32}>>>) -> i32`
is translat
[flang] Match the type of the element size in the box in getValueFromBox (#100512)
Currently, `%17 = fir.box_elesize %16 :
(!fir.class<!fir.ptr<!fir.type<_QFTt{a:i32,b:i32}>>>) -> i32`
is translated to
```
%4 = getelementptr { ptr, i64, i32, i8, i8, i8, i8, ptr, [1 x i64] }, ptr %1, i32 0, i32 1
%5 = load i32, ptr %4, align 4
```
The type of the element size is `i64`. The load essentially truncates
the value and yields incorrect result in the big endian environment. The
problem occurs in the `storage_size` intrinsic on a polymorphic
variable.
show more ...
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8 |
|
#
c0cba519 |
| 14-Jun-2024 |
Vijay Kandiah <vkandiah@nvidia.com> |
[Flang] Hoisting constant-sized allocas at flang codegen. (#95310)
This change modifies the `AllocaOpConversion` in flang codegen to insert
constant-sized LLVM allocas at the entry block of `LLVMFu
[Flang] Hoisting constant-sized allocas at flang codegen. (#95310)
This change modifies the `AllocaOpConversion` in flang codegen to insert
constant-sized LLVM allocas at the entry block of `LLVMFuncOp` or
OpenACC/OpenMP Op, rather than in-place at the `fir.alloca`. This
effectively hoists constant-sized FIR allocas to the proper block.
When compiling the example subroutine below with `flang-new`, we get a
llvm.stacksave/stackrestore pair around a constant-sized `fir.alloca
i32`.
```
subroutine test(n)
block
integer :: n
print *, n
end block
end subroutine test
```
Without the proposed change, downstream LLVM compilation cannot hoist
this constant-sized alloca out of the stacksave/stackrestore region
which may lead to missed downstream optimizations:
```
*** IR Dump After Safe Stack instrumentation pass (safe-stack) ***
define void @test_(ptr %0) !dbg !3 {
%2 = call ptr @llvm.stacksave.p0(), !dbg !7
%3 = alloca i32, i64 1, align 4, !dbg !8
%4 = call ptr @_FortranAioBeginExternalListOutput(i32 6, ptr @_QQclX62c91d05f046c7a656e7978eb13f2821, i32 4), !dbg !9
%5 = load i32, ptr %3, align 4, !dbg !10, !tbaa !11
%6 = call i1 @_FortranAioOutputInteger32(ptr %4, i32 %5), !dbg !10
%7 = call i32 @_FortranAioEndIoStatement(ptr %4), !dbg !9
call void @llvm.stackrestore.p0(ptr %2), !dbg !15
ret void, !dbg !16
}
```
With this change, the `llvm.alloca` is already hoisted out of the
stacksave/stackrestore region during flang codegen:
```
// -----// IR Dump After FIRToLLVMLowering (fir-to-llvm-ir) //----- //
llvm.func @test_(%arg0: !llvm.ptr {fir.bindc_name = "n"}) attributes {fir.internal_name = "_QPtest"} {
%0 = llvm.mlir.constant(4 : i32) : i32
%1 = llvm.mlir.constant(1 : i64) : i64
%2 = llvm.alloca %1 x i32 {bindc_name = "n"} : (i64) -> !llvm.ptr
%3 = llvm.mlir.constant(6 : i32) : i32
%4 = llvm.mlir.undef : i1
%5 = llvm.call @llvm.stacksave.p0() {fastmathFlags = #llvm.fastmath<contract>} : () -> !llvm.ptr
%6 = llvm.mlir.addressof @_QQclX62c91d05f046c7a656e7978eb13f2821 : !llvm.ptr
%7 = llvm.call @_FortranAioBeginExternalListOutput(%3, %6, %0) {fastmathFlags = #llvm.fastmath<contract>} : (i32, !llvm.ptr, i32) -> !llvm.ptr
%8 = llvm.load %2 {tbaa = [#tbaa_tag]} : !llvm.ptr -> i32
%9 = llvm.call @_FortranAioOutputInteger32(%7, %8) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr, i32) -> i1
%10 = llvm.call @_FortranAioEndIoStatement(%7) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> i32
llvm.call @llvm.stackrestore.p0(%5) {fastmathFlags = #llvm.fastmath<contract>} : (!llvm.ptr) -> ()
llvm.return
}
```
---------
Co-authored-by: Vijay Kandiah <vkandiah@sky6.pgi.net>
show more ...
|
Revision tags: llvmorg-18.1.7 |
|
#
e398383f |
| 30-May-2024 |
jeanPerier <jperier@nvidia.com> |
[flang][fir] add codegen for fir.load of assumed-rank fir.box (#93569)
- Update LLVM type conversion of assumed-rank fir.box/class to generate
the type of the maximum ranked descriptor. That way, a
[flang][fir] add codegen for fir.load of assumed-rank fir.box (#93569)
- Update LLVM type conversion of assumed-rank fir.box/class to generate
the type of the maximum ranked descriptor. That way, alloca for assumed
rank descriptor copies are always big enough. This is needed in the
fir.load case that generates a new storage for the value
- Add a "computeBoxSize" helper to compute the dynamic size of a
descriptor.
- Use that size to generate an llvm.memcpy intrinsic to copy the input
descriptor into the new storage.
Looking at https://reviews.llvm.org/D108221?id=404635, it seems valid to
add the TBAA node on the memcpy, which I did.
In a further patch, I think we should likely always use a memcpy since
LLVM seems to have a better time optimizing it than fir.load/fir.store
patterns.
show more ...
|
#
26e0ce0b |
| 28-May-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] update fir.box_rank and fir.is_array codegen (#93541)
fir.box_rank codegen was invalid, it was assuming the rank field in the
descriptor was an i32. This is not correct. Do not hard code th
[flang] update fir.box_rank and fir.is_array codegen (#93541)
fir.box_rank codegen was invalid, it was assuming the rank field in the
descriptor was an i32. This is not correct. Do not hard code the type,
use the named position to find the type, and convert as needed in the
patterns.
show more ...
|
Revision tags: llvmorg-18.1.6, llvmorg-18.1.5 |
|
#
0632cb38 |
| 01-May-2024 |
Kareem Ergawy <kareem.ergawy@amd.com> |
[flang][MLIR] Outline deallocation logic to `omp.private` ops (#90592)
When delayed privatization is enabled, this PR emits the deallocation
logic to the newly introduced `dealloc` region on `omp.p
[flang][MLIR] Outline deallocation logic to `omp.private` ops (#90592)
When delayed privatization is enabled, this PR emits the deallocation
logic to the newly introduced `dealloc` region on `omp.private` ops.
show more ...
|
#
3785d742 |
| 29-Apr-2024 |
Kareem Ergawy <kareem.ergawy@amd.com> |
[flang][OpenMP][LLVMIR] Support CFG and LLVM IR conversion for `omp.p… (#90164)
…rivate`
Adds support for CFG conversion and conversion to LLVM IR for
`omp.private` ops. This bridges a gap betwe
[flang][OpenMP][LLVMIR] Support CFG and LLVM IR conversion for `omp.p… (#90164)
…rivate`
Adds support for CFG conversion and conversion to LLVM IR for
`omp.private` ops. This bridges a gap between FIR and LLVM to provide
more support for lowering `omp.private` ops for things like
allocatables.
show more ...
|
#
fac349a1 |
| 28-Apr-2024 |
Christian Sigg <chsigg@users.noreply.github.com> |
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)
…ted. (#89998)" (#90250)
This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.
This change rem
Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)
…ted. (#89998)" (#90250)
This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.
This change removes calls to the deprecated member functions. It does
not mark the functions deprecated yet and does not disable the
deprecation warning in TypeSwitch. This seems to cause problems with
MSVC.
show more ...
|
#
7aedd7dc |
| 26-Apr-2024 |
dyung <douglas.yung@sony.com> |
Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)
This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.
This change is causing build failures on
Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)
This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.
This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157
show more ...
|
#
950b7ce0 |
| 26-Apr-2024 |
Christian Sigg <chsigg@users.noreply.github.com> |
[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)
See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.
|
Revision tags: llvmorg-18.1.4, llvmorg-18.1.3 |
|
#
e9639e9c |
| 22-Mar-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][NFC] Extract FIROpConversion to its own files (#86213)
This PR extracts `FIROpConversion` and `FIROpAndTypeConversion`
templated base patterns to a header file. All the functions from
FIRO
[flang][NFC] Extract FIROpConversion to its own files (#86213)
This PR extracts `FIROpConversion` and `FIROpAndTypeConversion`
templated base patterns to a header file. All the functions from
FIROpConversion that do not require the template argument are moved to a
base class named `ConvertFIRToLLVMPattern`.
This move is done so the `FIROpConversion` pattern and all its utility
functions can be reused outside of the codegen pass.
For the most part the code is only moved to the new files and not
modified. The only update is that addition of the PatternBenefit
argument with a default value to the constructor so it can be forwarded
to the `ConversionPattern` ctor.
This split is done in a similar way for the `ConvertOpToLLVMPattern`
base pattern that is based on the `ConvertToLLVMPattern` base class in
`mlir/include/mlir/Conversion/LLVMCommon/Pattern.h`.
show more ...
|