History log of /llvm-project/flang/lib/Optimizer/CodeGen/BoxedProcedure.cpp (Results 26 – 35 of 35)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 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 ...


12