#
33b93044 |
| 28-Aug-2022 |
Kazu Hirata <kazu@google.com> |
Use llvm::is_contained (NFC)
|
Revision tags: llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
c715e2ff |
| 16-Jul-2022 |
Kazu Hirata <kazu@google.com> |
[flang] Use value_or (NFC)
|
#
906784a3 |
| 12-Jul-2022 |
Jean Perier <jperier@nvidia.com> |
[flang] move getKindMapping() calls out of FIROpBuilder ctor calls
FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping() call is made inside the ctor call, the lifetime of this
[flang] move getKindMapping() calls out of FIROpBuilder ctor calls
FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping() call is made inside the ctor call, the lifetime of this reference may be as short as the ctor call (at least with when building flang in release mode with clang 8). This can cause segfaults when later using the FirOpBuilder.
Ensure the kindMap passed to the FirOpBuilder ctor is the same as the FirOpBuilder.
Differential Revision: https://reviews.llvm.org/D129494
show more ...
|
#
86b8c1d9 |
| 10-Jul-2022 |
Kazu Hirata <kazu@google.com> |
[flang] Don't use Optional::hasValue (NFC)
Flang C++ Style Guide tells us to avoid .has_value() in the predicate expressions of control flow statements. I am treating ternary expressions as control
[flang] Don't use Optional::hasValue (NFC)
Flang C++ Style Guide tells us to avoid .has_value() in the predicate expressions of control flow statements. I am treating ternary expressions as control flow statements for the purpose of this patch.
Differential Revision: https://reviews.llvm.org/D128622
show more ...
|
#
3b7c3a65 |
| 25-Jun-2022 |
Kazu Hirata <kazu@google.com> |
Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
|
#
aa8feeef |
| 25-Jun-2022 |
Kazu Hirata <kazu@google.com> |
Don't use Optional::hasValue (NFC)
|
Revision tags: llvmorg-14.0.6 |
|
#
c67a8744 |
| 21-Jun-2022 |
Valentin Clement <clementval@gmail.com> |
[flang] Add more diagnostics to fir.coordinate_of
Add more diagnostics to fir.coordinate_of to provide better checking that the IR is sane.
This patch is part of the upstreaming effort from fir-dev
[flang] Add more diagnostics to fir.coordinate_of
Add more diagnostics to fir.coordinate_of to provide better checking that the IR is sane.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D128255
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
show more ...
|
#
a370a4ff |
| 13-Jun-2022 |
jeanPerier <jeanPerier@users.noreply.github.com> |
[flang] Avoid raising a TODO in fir.boxproc rewrite when not needed (#1560)
The pass was raising TODOs when a function both had a fir.boxproc<> argument and a fir.type<> argument (even if the fir.ty
[flang] Avoid raising a TODO in fir.boxproc rewrite when not needed (#1560)
The pass was raising TODOs when a function both had a fir.boxproc<> argument and a fir.type<> argument (even if the fir.type<> did not contain a fir.boxproc itself).
Prevent the TODO from firing when a fir.type<> does not actually contain a fir.boxproc. Add the location for the remaining TODO (it will be needed when procedure pointer components are supported in lowering).
FYI, I actually tried to just implement the TODO, but I there is a funny issue. When creating the new fir::RecordType, since the name and context are the same as the type being translated, fir::RecordType:get just returns the existing type, and there is no way to change it (finalize() does nothing since it is already finalized). So this will require to add the ability to mutate the existing type, and I am not sure what are the MLIR constraints here, so I escaped and left the TODO for that case.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D127633
Co-authored-by: Jean Perier <jperier@nvidia.com>
show more ...
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
#
58ceae95 |
| 18-Apr-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace
FuncOp has been moved to the `func` namespace for a little over a month, the using directive can be dropped now.
|
Revision tags: llvmorg-14.0.1 |
|
#
fe252f8e |
| 22-Mar-2022 |
Valentin Clement <clementval@gmail.com> |
[flang] Lower boxed procedure
In FIR, we want to wrap function pointers in a special box known as a boxproc value. Fortran has a limited form of dynamic scoping [https://tinyurl.com/2p8v2hw7] betwee
[flang] Lower boxed procedure
In FIR, we want to wrap function pointers in a special box known as a boxproc value. Fortran has a limited form of dynamic scoping [https://tinyurl.com/2p8v2hw7] between "host procedures" and "internal procedures". There are a number of implementations possible.
Boxproc typed values abstract away the implementation details of when a function pointer can be passed directly (as a raw address) and when a function pointer has to account for the presence of a dynamic scope. When lowering Fortran syntax to FIR, all function pointers are emboxed as boxproc values.
When creating LLVM IR, we must strip away the abstraction and produce low-level LLVM "assembly" code. This patch implements that transformation as converting the boxproc values to either raw function pointers or executable trampolines on the stack as needed. The trampoline then captures the dynamic scope context within an executable thunk that can be passed instead of the function's raw address.
Some extra handling is required for Fortran functions that return a character value to deal with LEN values here.
Some of the code in Bridge.cpp and ConvertExpr.cpp and be re-arranged to faciliate the upstreaming effort.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D122223
Co-authored-by: mleair <leairmark@gmail.com> Co-authored-by: Jean Perier <jperier@nvidia.com> Co-authored-by: Eric Schweitz <eschweitz@nvidia.com> Co-authored-by: V Donaldson <vdonaldson@nvidia.com> Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
show more ...
|