Revision tags: llvmorg-21-init |
|
#
ce326259 |
| 21-Jan-2025 |
Kiran Chandramohan <kiran.chandramohan@arm.com> |
Reland "[Flang][Driver] Add a flag to control zero initialization" (#123606)
Reverts llvm/llvm-project#123330
|
#
8a229f59 |
| 17-Jan-2025 |
Kiran Chandramohan <kiran.chandramohan@arm.com> |
Revert "Revert "Revert "[Flang][Driver] Add a flag to control zero initializa…" (#123330)
Reverts llvm/llvm-project#123097
Reverting due to buildbot failure
https://lab.llvm.org/buildbot/#/build
Revert "Revert "Revert "[Flang][Driver] Add a flag to control zero initializa…" (#123330)
Reverts llvm/llvm-project#123097
Reverting due to buildbot failure
https://lab.llvm.org/buildbot/#/builders/89/builds/14577.
show more ...
|
#
8c636481 |
| 17-Jan-2025 |
Kiran Chandramohan <kiran.chandramohan@arm.com> |
Revert "Revert "[Flang][Driver] Add a flag to control zero initializa… (#123097)
…tion of global v…" (#123067)"
This reverts commit 44ba43aa2b740878d83a9d6f1d52a333c0d48c22.
Adds the flag to b
Revert "Revert "[Flang][Driver] Add a flag to control zero initializa… (#123097)
…tion of global v…" (#123067)"
This reverts commit 44ba43aa2b740878d83a9d6f1d52a333c0d48c22.
Adds the flag to bbc as well.
show more ...
|
#
44ba43aa |
| 15-Jan-2025 |
Kiran Chandramohan <kiran.chandramohan@arm.com> |
Revert "[Flang][Driver] Add a flag to control zero initialization of global v…" (#123067)
Reverts llvm/llvm-project#122144
Reverting due to CI failure
https://lab.llvm.org/buildbot/#/builders/89
Revert "[Flang][Driver] Add a flag to control zero initialization of global v…" (#123067)
Reverts llvm/llvm-project#122144
Reverting due to CI failure
https://lab.llvm.org/buildbot/#/builders/89/builds/14422
show more ...
|
#
c593e3d0 |
| 15-Jan-2025 |
Kiran Chandramohan <kiran.chandramohan@arm.com> |
[Flang][Driver] Add a flag to control zero initialization of global v… (#122144)
…ariables
Patch adds a flag to control zero initialization of global variables
without default initialization. Th
[Flang][Driver] Add a flag to control zero initialization of global v… (#122144)
…ariables
Patch adds a flag to control zero initialization of global variables
without default initialization. The default is to zero initialize.
show more ...
|
Revision tags: llvmorg-19.1.7 |
|
#
1fcb6a97 |
| 19-Dec-2024 |
Leandro Lupori <leandro.lupori@linaro.org> |
[flang][OpenMP] Initialize allocatable members of derived types (#120295)
Allocatable members of privatized derived types must be allocated,
with the same bounds as the original object, whenever th
[flang][OpenMP] Initialize allocatable members of derived types (#120295)
Allocatable members of privatized derived types must be allocated,
with the same bounds as the original object, whenever that member
is also allocated in it, but Flang was not performing such
initialization.
The `Initialize` runtime function can't perform this task unless
its signature is changed to receive an additional parameter, the
original object, that is needed to find out which allocatable
members, with their bounds, must also be allocated in the clone.
As `Initialize` is used not only for privatization, sometimes this
other object won't even exist, so this new parameter would need
to be optional.
Because of this, it seemed better to add a new runtime function:
`InitializeClone`.
To avoid unnecessary calls, lowering inserts a call to it only for
privatized items that are derived types with allocatable members.
Fixes https://github.com/llvm/llvm-project/issues/114888
Fixes https://github.com/llvm/llvm-project/issues/114889
show more ...
|
Revision tags: llvmorg-19.1.6 |
|
#
c91ba043 |
| 06-Dec-2024 |
Michael Kruse <llvm-project@meinersbur.de> |
[Flang][NFC] Split runtime headers in preparation for cross-compilation. (#112188)
Split some headers into headers for public and private declarations in
preparation for #110217. Moving the runtime
[Flang][NFC] Split runtime headers in preparation for cross-compilation. (#112188)
Split some headers into headers for public and private declarations in
preparation for #110217. Moving the runtime-private headers in
runtime-private include directory will occur in #110298.
* Do not use `sizeof(Descriptor)` in the compiler. The size of the
descriptor is target-dependent while `sizeof(Descriptor)` is the size of
the Descriptor for the host platform which might be too small when
cross-compiling to a different platform. Another problem is that the
emitted assembly ((cross-)compiling to the same target) is not identical
between Flang's running on different systems. Moving the declaration of
`class Descriptor` out of the included header will also reduce the
amount of #included sources.
* Do not use `sizeof(ArrayConstructorVector)` and
`alignof(ArrayConstructorVector)` in the compiler. Same reason as with
`Descriptor`.
* Compute the descriptor's extra flags without instantiating a
Descriptor. `Fortran::runtime::Descriptor` is defined in the runtime
source, but not the compiler source.
* Move `InquiryKeywordHashDecode` into runtime-private header. The
function is defined in the runtime sources and trying to call it in the
compiler would lead to a link-error.
* Move allocator-kind magic numbers into common header. They are the
only declarations out of `allocator-registry.h` in the compiler as well.
This does not make Flang cross-compile ready yet, the main goal is to
avoid transitive header dependencies from Flang to clang-rt. There are
more assumptions that host platform is the same as the target platform.
show more ...
|
Revision tags: llvmorg-19.1.5 |
|
#
cf602b95 |
| 26-Nov-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] handle fir.call in AliasAnalysis::getModRef (#117164)
fir.call side effects are hard to describe in a useful way using
`MemoryEffectOpInterface` because it is impossible to list which memor
[flang] handle fir.call in AliasAnalysis::getModRef (#117164)
fir.call side effects are hard to describe in a useful way using
`MemoryEffectOpInterface` because it is impossible to list which memory
location a user procedure read/write without doing a data flow analysis
of its body (even PURE procedures may read from any module variable,
Fortran SIMPLE procedure from F2023 will allow that, but they are far
from common at that point).
Fortran language specifications allow the compiler to deduce
that a procedure call cannot access a variable in many cases
This patch leverages this to extend `fir::AliasAnalysis::getModRef` to
deal with fir.call.
This will allow implementing "array = array_function()" optimization in
a future patch.
show more ...
|
#
bb8bf858 |
| 26-Nov-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] add internal_assoc flag to mark variable captured in internal procedure (#117161)
This patch adds a flag to mark hlfir.declare of host variables that are
captured in some internal procedure
[flang] add internal_assoc flag to mark variable captured in internal procedure (#117161)
This patch adds a flag to mark hlfir.declare of host variables that are
captured in some internal procedure.
It enables implementing a simple fir.call handling in
fir::AliasAnalysis::getModRef leveraging Fortran language specifications
and without a data flow analysis.
This will allow implementing an optimization for "array =
array_function()" where array storage is passed directly into the hidden
result argument to "array_function" when it can be proven that
arraY_function does not reference "array".
Captured host variables are very tricky because they may be accessed
indirectly in any calls if the internal procedure address was captured
via some global procedure pointer. Without flagging them, there is no
way around doing a complex inter procedural data flow analysis:
- checking that the call is not made to an internal procedure is not
enough because of the possibility of indirect calls made to internal
procedures inside the callee.
- checking that the current func.func has no internal procedure is not
enough because this would be invalid with inlining when an procedure
with internal procedures is inlined inside a procedure without internal
procedure.
show more ...
|
Revision tags: llvmorg-19.1.4, llvmorg-19.1.3 |
|
#
e6a4346b |
| 18-Oct-2024 |
Scott Manley <rscottmanley@gmail.com> |
[flang] add getElementType() to fir::SquenceType and fir::VectorType (#112770)
getElementType() was missing from Sequence and Vector types. Did a
replace of the obvious places getEleTy() was used f
[flang] add getElementType() to fir::SquenceType and fir::VectorType (#112770)
getElementType() was missing from Sequence and Vector types. Did a
replace of the obvious places getEleTy() was used for these two types
and updated to use this name instead.
Co-authored-by: Scott Manley <scmanley@nvidia.com>
show more ...
|
Revision tags: llvmorg-19.1.2 |
|
#
ccca3c63 |
| 04-Oct-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] enable assumed-rank lowering by default (#110893)
Aside from a minor TODO about polymorphic RANK(*) (https://github.com/llvm/llvm-project/blob/2b8e81ce919e8db857dc2ba20012e9020af07294/flang/
[flang] enable assumed-rank lowering by default (#110893)
Aside from a minor TODO about polymorphic RANK(*) (https://github.com/llvm/llvm-project/blob/2b8e81ce919e8db857dc2ba20012e9020af07294/flang/lib/Lower/Bridge.cpp#L3459),
the implementation for assumed-rank is ready for everyone to use.
show more ...
|
#
c4204c0b |
| 03-Oct-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] replace fir.complex usages with mlir complex (#110850)
Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last s
[flang] replace fir.complex usages with mlir complex (#110850)
Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last step is to remove fir.complex from FIR types.
show more ...
|
Revision tags: llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
0dcd68c2 |
| 30-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Set allocator index for module allocatable variable (#106777)
Descriptor for module variable with cuda attribute must be set with the
correct allocator index. This patch updates the e
[flang][cuda] Set allocator index for module allocatable variable (#106777)
Descriptor for module variable with cuda attribute must be set with the
correct allocator index. This patch updates the embox operation used in
the global to carry the allocator index.
show more ...
|
Revision tags: llvmorg-19.1.0-rc3 |
|
#
5bb379f6 |
| 13-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Fix allocation of descriptor for cray pointer (#103474)
The cray pointee descriptor with device attribute was not allocated with
cuf.alloc so it leads to error on deallocation with cu
[flang][cuda] Fix allocation of descriptor for cray pointer (#103474)
The cray pointee descriptor with device attribute was not allocated with
cuf.alloc so it leads to error on deallocation with cuf.free.
show more ...
|
#
388b6324 |
| 06-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Defined allocator for unified data (#102189)
CUDA unified variable where set to use the same allocator than managed
variable. This patch adds a specific allocator for the unified
var
[flang][cuda] Defined allocator for unified data (#102189)
CUDA unified variable where set to use the same allocator than managed
variable. This patch adds a specific allocator for the unified
variables. Currently it will call the managed allocator underneath but
we want to have the flexibility to change that in the future.
show more ...
|
Revision tags: llvmorg-19.1.0-rc2 |
|
#
bbdb1e40 |
| 02-Aug-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Set the allocator on fir.embox operation (#101722)
This patch set the `allocator_idx` attribute for allocatable descriptor
that have specific CUDA attribute.
|
Revision tags: llvmorg-19.1.0-rc1 |
|
#
98e733ea |
| 25-Jul-2024 |
Tom Eccles <tom.eccles@arm.com> |
[flang][OpenMP] Initialize privatised derived type variables (#100417)
Fixes #91928
|
Revision tags: llvmorg-20-init |
|
#
33cb29cc |
| 17-Jul-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Use cuf.alloc/cuf.free for local descriptor (#98518)
Local descriptor for cuda allocatable need to be handled on host and
device. One solution is to duplicate the descriptor (one on
[flang][cuda] Use cuf.alloc/cuf.free for local descriptor (#98518)
Local descriptor for cuda allocatable need to be handled on host and
device. One solution is to duplicate the descriptor (one on the host and
one on the device) and keep them in sync or have the descriptor in
managed/unified memory so we don't to take care of any sync.
The second solution is probably the one we will implement. In order to
have more flexibility on how descriptor representing cuda allocatable
are allocated, this patch updates the lowering to use the cuf operations
alloc and free to managed them.
show more ...
|
#
8f90258a |
| 20-Jun-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] implement assumed-rank in ENTRY (#96111)
With `createUnallocatedBox` utility change from #96106 , the TODO for assumed-rank in entry
can simply be lifted and test is added.
The key is th
[flang] implement assumed-rank in ENTRY (#96111)
With `createUnallocatedBox` utility change from #96106 , the TODO for assumed-rank in entry
can simply be lifted and test is added.
The key is that a unallocated assumed-rank descriptor is created with
rank zero in the entry where an assumed-rank dummy from some other entry
do not appear as a dummy (the symbol must still be mapped to some valid
value because the symbol could be used in code that would be unreachable
at runtime, but that the compiler must still generate).
show more ...
|
Revision tags: llvmorg-18.1.8 |
|
#
3a47d948 |
| 14-Jun-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Propagate data attribute to global with initialization (#95504)
Global with initial value were missing the CUDA data attribute.
|
Revision tags: llvmorg-18.1.7 |
|
#
c1654c38 |
| 04-Jun-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang] Carry over alignment computed by frontend for COMMON (#94280)
The frontend computes the necessary alignment for COMMON blocks but this
information is never carried over to the code generati
[flang] Carry over alignment computed by frontend for COMMON (#94280)
The frontend computes the necessary alignment for COMMON blocks but this
information is never carried over to the code generation and can lead to
segfault for COMMON block that requires a non default alignment.
This patch add an optional attribute on fir.global and carries over the
information.
show more ...
|
#
74faa402 |
| 30-May-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] lower allocatable assumed-rank specification parts (#93682)
Lower allocatable and pointers specification parts. Nothing special is
required to allocate the descriptor given they are require
[flang] lower allocatable assumed-rank specification parts (#93682)
Lower allocatable and pointers specification parts. Nothing special is
required to allocate the descriptor given they are required to be dummy
arguments, however, care must be taken with INTENT(OUT) to use the
runtime to deallocate them (inlined fir.embox + store is not possible).
show more ...
|
#
5aba0ded |
| 29-May-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] lower assumed-rank variables specification expressions (#93477)
Enable lowering of assumed-ranks in specification parts under a debug
flag. I am using a debug flag because many cryptic TODO
[flang] lower assumed-rank variables specification expressions (#93477)
Enable lowering of assumed-ranks in specification parts under a debug
flag. I am using a debug flag because many cryptic TODOs/issues may be
hit until more support is added. The development should not take too
long, so I want to stay away from the noise of adding an actual
experimental flag to flang-new.
show more ...
|
Revision tags: llvmorg-18.1.6 |
|
#
702198fc |
| 18-May-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Add data attribute to program globals (#92610)
|
#
45daa4fd |
| 17-May-2024 |
Valentin Clement (バレンタイン クレメン) <clementval@gmail.com> |
[flang][cuda] Move CUDA Fortran operations to a CUF dialect (#92317)
The number of operations dedicated to CUF grew and where all still in
FIR. In order to have a better organization, the CUF opera
[flang][cuda] Move CUDA Fortran operations to a CUF dialect (#92317)
The number of operations dedicated to CUF grew and where all still in
FIR. In order to have a better organization, the CUF operations,
attributes and code is moved into their specific dialect and files. CUF
dialect is tightly coupled with HLFIR/FIR and their types.
The CUF attributes are bundled into their own library since some
HLFIR/FIR operations depend on them and the CUF dialect depends on the
FIR types. Without having the attributes into a separate library there
would be a dependency cycle.
show more ...
|