|
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 |
|
| #
d9250061 |
| 26-Sep-2024 |
jeanPerier <jperier@nvidia.com> |
[flang] add fir.proc_attrs attributes to func.func (#110002)
BIND(C) ABI need care in the TargetRewrite pass. currently, we are not
able to accurately identify fun.func that are BIND(C) in FIR (the
[flang] add fir.proc_attrs attributes to func.func (#110002)
BIND(C) ABI need care in the TargetRewrite pass. currently, we are not
able to accurately identify fun.func that are BIND(C) in FIR (the
fir.bindc_name is used in other contexts, like for program names).
This patch adds the fir.proc_attrs to func.func just like it was done
for calls recently. This replace the previous named attribute for
PURE/ELEMENTAL/RECURSIVE (note that RECURSIVE is changed to
NON_RECURSIVE, which brings more data since RECURSIVE is the default for
procedures that do not have explicit RECURSIVE/NON_RECUSRIVE
attributes).
show more ...
|
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5 |
|
| #
f35f863a |
| 13-Nov-2023 |
jeanPerier <jperier@nvidia.com> |
[flang][NFC] Use hlfir=false and flang-deprecated-no-hlfir in legacy tests (#71957)
Patch 2/3 of the transition step 1 described in
https://discourse.llvm.org/t/rfc-enabling-the-hlfir-lowering-by
[flang][NFC] Use hlfir=false and flang-deprecated-no-hlfir in legacy tests (#71957)
Patch 2/3 of the transition step 1 described in
https://discourse.llvm.org/t/rfc-enabling-the-hlfir-lowering-by-default/72778/7.
All the modified tests are still here since coverage for the direct
lowering to FIR was still needed while it was default. Some already have
an HLFIR version, some have not and will need to be ported in step 2
described in the RFC.
Note that another 147 lit tests use -emit-fir/-emit-llvm outputs but do
not need a flag since the HLFIR/no HLFIR output is the same for what is
being tested.
show more ...
|
|
Revision tags: llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2 |
|
| #
ab9c4e9f |
| 07-Feb-2023 |
Jean Perier <jperier@nvidia.com> |
[flang][NFC] addSymbol/lookupSymbol clean-up
HLFIR requires mapping symbol to a single mlir::Value (produced
by a fir::FortranVariableOpInterface), while the current lowering
maps the value to a fir
[flang][NFC] addSymbol/lookupSymbol clean-up
HLFIR requires mapping symbol to a single mlir::Value (produced
by a fir::FortranVariableOpInterface), while the current lowering
maps the value to a fir::ExtdendedValue.
So far, the HLFIR symbol query was a special one. Hence, all the code
directly using symMap.lookupSymbol and symMap.addSymbol did not work
with the lowering to HLFIR.
Refactor the code so that symbol lookup and add symbol go through
the converter in a centralize place that handles the HLFIR case
(translate fir::FortranVariableOpInterface to fir::ExtdendedValue
in lookups, and generate hlfir.declare when adding symbols).
In the refactoring, fir::FortranVariableOpInterface is added as
a symbolBox variant to avoid special casing all lookups (shallowLookup...).
Remove some unused SymbolBox member function instead of updating
them.
Differential Revision: https://reviews.llvm.org/D143395
show more ...
|
|
Revision tags: llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5 |
|
| #
4cc9437a |
| 11-Nov-2022 |
Tom Eccles <tom.eccles@arm.com> |
[flang] Set default to -ffpcontract=fast
Following RFC at
https://discourse.llvm.org/t/rfc-ffp-contract-default-value/66301
This adds the `fastmath<contract>` attribute to `fir.call` and some
float
[flang] Set default to -ffpcontract=fast
Following RFC at
https://discourse.llvm.org/t/rfc-ffp-contract-default-value/66301
This adds the `fastmath<contract>` attribute to `fir.call` and some
floating point arithmetic operations (hence the many test changes).
Instead of testing for this specific attribute, I am using a regular
expression to match any attributes.
show more ...
|
|
Revision tags: llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0 |
|
| #
4943dbdf |
| 29-Aug-2022 |
Peixin Qiao <qiaopeixin@huawei.com> |
[flang] Support lowering of C_PTR and C_FUNPTR argument with VALUE attribute
As Fortran 2018 18.3.2, C_PTR is interoperable with any C object pointer
type. C_FUNPTR is interoperable with any C funct
[flang] Support lowering of C_PTR and C_FUNPTR argument with VALUE attribute
As Fortran 2018 18.3.2, C_PTR is interoperable with any C object pointer
type. C_FUNPTR is interoperable with any C function pointer type. As
18.3.6, a C pointer can correspond to a Fortran dummy argument of type
C_PTR with the VALUE attribute.
The interface for type(C_PTR)/type(C_FUNPTR) argument with value
attribute is different from the the usual derived type. For type(C_PTR)
or type(C_FUNPTR), the component is the address, and the interface is
a pointer even with VALUE attribute. For a usual derived type such as
the drived type with the component of integer 64, the interface is a i64
value when it has VALUE attribute on aarch64 linux.
To lower the type(C_PTR)/type(C_FUNPTR) argument with value attribute,
get the value of the component of the type(C_PTR)/type(C_FUNPTR), which
is the address, and then convert it to the pointer and pass it.
Reviewed By: Jean Perier
Differential Revision: https://reviews.llvm.org/D131583
show more ...
|