Fix https://github.com/flang-compiler/f18-llvm-project/issues/1416.
The `constRows` variable was being decremented too soon, causing the
last constant interior dimension extent being used to multiply the GEP
offset. This lead to wrong address computation and caused segfaults.
Note: also upstream fir.embox tests that can be upstreamed.
Differential Revision: https://reviews.llvm.org/D123130
Do not use the shift of a fir.embox to set lower bounds if there is
a fir.slice operand. This matches Fortran semantics where lower bounds
of array sections are ones.
Note that in case there is a fir.slice, the array shift may be provided
because it is used to calculate the origin/base address of an array slice.
Add a TODO for substring codegen since I noticed it was not upstreamed
yet and would cause some program to silently compile incorrectly.
Differential Revision: https://reviews.llvm.org/D123123
This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.
To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.
This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.
Differential Revision: https://reviews.llvm.org/D122775
These are mostly small changes to make the code a bit clearer and more
consistent. Summary of changes:
* add missing namespace qualifiers (that's the preference in Flang)
* replace const member methods with static methods (to avoid passing
the *this pointer unnecessarily)
* rename `currentObjTy` (current object type) as `cpnTy` (component
type) - the latter feels more fitting
* remove redundant `return failure();` calls (` return
mlir::emitError` gives the same result)
* updated a few comments
Differential Revision: https://reviews.llvm.org/D122799
This patch addes some global initialization and global
box initialization tests.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D122881
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Follow-up of https://reviews.llvm.org/D121488 to ensure all descriptors
created inline complies with LBOUND requirement that the lower bound is
`1` when the related dimension extent is zero.
Both fir.xrebox and fir.xembox codegen is updated to enforce this
constraint.
Also upstream the "normalized lower bound" attribute that was added in fir-dev
since embox codegen was upstreamed, it is conflicting with this patch
otherwise.
Differential Revision: https://reviews.llvm.org/D122419
This patch adds the OpenMP conversion patterns to the FIR to LLVM
dialect lowering pass in Codegen. Appropriate legalization
conditions are also added. This ensures that a mix of FIR and OpenMP
dialects can be lowered to LLVM and OpenMP dialects. Also adds two
tests.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: clementval, peixin
Differential Revision: https://reviews.llvm.org/D121793
Co-authored-by: Sourabh Singh Tomar <SourabhSingh.Tomar@amd.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Currently, CGOps.h and FIROps.h contain `using namespace mlir;`. Every
file that includes one of these header files (directly and transitively)
will have the MLIR namespace enabled. With name-clashes within
sub-projects (LLVM and MLIR, MLIR and Flang), this is not desired. Also,
it is not possible to "un-use" a namespace once it is "used". Instead,
we should try to limit `using namespace` to implementation files (i.e.
*.cpp).
This patch removes `using namespace mlir;` from header files and adjusts
other files accordingly. In header and TableGen files, extra namespace
qualifier is added when referring to symbols defined in MLIR. Similar
approach is adopted in source files that didn't require many changes. In
files that would require a lot of changes, `using namespace mlir;` is
added instead.
Differential Revision: https://reviews.llvm.org/D120897
The front-end and the runtime are currently using the unix logical
representation, but lowering was not. These inconsistencies could
caused issues.
The only place that defines what the logical representation is in
lowering is the translation from FIR to LLVM (FIR is agnostic to the
actual representation). More precisely, the LLVM implementation of
`fir.convert` between `i1` and `fir.logcial` is what defines the
representation:
- `fir.convert` from `i1` to `fir.logical` defines the `.true.` and `.false.`
canonical representations
- `fir.convert` from `fir.logical` to `i1` decides what the test for
truth is.
Unix representation is:
- .true. canonical integer representation is 1
- .false. canonical integer representation is 0
- the test for truth is "integer representation != 0"
For the record, the previous representation that was used was in
codegen was:
- .true. canonical integer representation is -1 (all bits 1)
- .false. canonical integer representation is 0
- the test for truth is "integer representation lowest bit == 1"
Differential Revision: https://reviews.llvm.org/D121200
The current StandardToLLVM conversion patterns only really handle
the Func dialect. The pass itself adds patterns for Arithmetic/CFToLLVM, but
those should be/will be split out in a followup. This commit focuses solely
on being an NFC rename.
Aside from the directory change, the pattern and pass creation API have been renamed:
* populateStdToLLVMFuncOpConversionPattern -> populateFuncToLLVMFuncOpConversionPattern
* populateStdToLLVMConversionPatterns -> populateFuncToLLVMConversionPatterns
* createLowerToLLVMPass -> createConvertFuncToLLVMPass
Differential Revision: https://reviews.llvm.org/D120778
This change updates the mapping of derived types and type descriptor
object names to support kind parametrized derived types (PDT).
It moves the custom name mapping to the internal name utility.
To improve robustness and error reporting, type descriptors are also now
required to be generated in all compilation unit that manipulates
derived types. The previous codegen relied on the fact that descriptors
not defined in the current FIR module were available externally. Errors
with missing type descriptors were only caught at link time.
This patch makes derived type definition mandatory, except if the
derived types are expected to not have derived type descriptors (builtin
types), or if the newly added debug switch `--ignore-missing-type-desc`
is set. In those cases, a null pointer is used as type descriptor
pointer. The debug switch intends to help testing FIR to LLVM passes
without having to bother providing type descriptor data structures that
are normally built by the front-end.
Differential Revision: https://reviews.llvm.org/D120804
Minor rearrangment in the order of conversion patterns to identify
differences.
Reviewed By: clementval, schweitz
Differential Revision: https://reviews.llvm.org/D120721
Minor comment updates and use getVoidPtr helper instead of
builiding `i8*` type manually in codegen.
Differential Revision: https://reviews.llvm.org/D119828
`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119812
Currently, code generation was creating weak symbols for derived type
descriptor global it could not find in the current compilation unit.
The rational is that:
- the derived type descriptors of external module derived types are
generated in the compilation unit that compiled the module so that
the type descriptor address is uniquely associated with the type.
- some types do not have derived type descriptors: the builtin derived
types used to create derived type descriptors. The runtime knows
about them and does not need them to accomplish the feat of
describing themselves. Hence, all unresolved derived type descriptors
in codegen cannot be assumed to be resolved at link time.
However, this caused immense debugging pain when, for some reasons, derived
type descriptor that should be generated were not. This caused random
runtime failures instead of a much cleaner link time failure.
Improve this situation by allowing codegen to detect the builtin derived
types that have no derived type descriptors and requiring the other
unresolved derived type descriptor to be resolved at link time.
Also make derived type descriptor constant data since this was a TODO
and makes the situation even cleaner. This requiring telling lowering
which compiler created symbols can be placed in read only memory. I
considered using PARAMETER, but I have mixed feeling using it since that
would cause the initializer expressions of derived type descriptor to
be invalid from a Fortran point of view since pointer targets cannot be
parameters. I do not want to start misusing Fortran attributes, even if
I think it is quite unlikely semantics would currently complain. I also
do not want to rely on the fact that all object symbols with the
CompilerCreated flags are currently constant data. This could easily
change in the future and cause runtime bugs if lowering rely on this
while the assumption is not loud and clear in semantics.
Instead, add a ReadOnly symbol flag to tell lowering that a compiler
generated symbol can be placed in read only memory.
Differential Revision: https://reviews.llvm.org/D119555
for sequence of character types.
Upstream type test. Upstream test. Fix tests.
Do not run on windows, as that is not an implemented target.
Differential Revision: https://reviews.llvm.org/D119551
OwningRewritePatternList has been deprecated for ~10 months now, we can remove
the leftover using directives at this point.
Differential Revision: https://reviews.llvm.org/D118287
getLoweredName() is not a well suited name change it to
translateNameToFrontendMangledName()
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D118140
tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler.
This patch update tco pipelines and adds the translation to LLVM IR.
A simple test is added to make sure the tool is working with a simple
FIR program.
More tests will be upstream in follow up patch from the fir-dev branch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D117781
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler.
This patch update tco pipelines and adds the translation to LLVM IR.
A simple test is added to make sure the tool is working with a simple
FIR program.
More tests will be upstream in follow up patch from the fir-dev branch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D117781
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
When converting a fir.alloca of an array to the LLVM dialect, we used to
multiply the allocated size by all the constant factors encoded in the
array type. This is fine when the array type is converted to the element
type for the purposes of the allocation, but if it's converted to an
array type, then we might be allocating too much space. For example, for
`%2 = fir.alloca !fir.array<8x16x32xf32>, %0, %1` we would allocate
%0 * %1 * 8 * 16 * 32 x llvm.array<32 x array<16 * array<8 x f32>>>. We
really only need to allocate %0 * %1 such arrays.
This patch fixes the issue by taking note of the array type that we're
trying to allocate. It tries to match the behaviour of
LLVMTypeConverter::convertPointerLike, which returns a pointer to the
element type only when the array type doesn't have a constant interior.
We consequently only multiply with the constant factors in the array
type if the array type doesn't have a constant interior.
This has the nice side effect that it gets rid of some redundant
multiplications with the constant 1 in some cases.
Differential Revision: https://reviews.llvm.org/D116926
This patch extends the `FIRToLLVMLowering` pass in Flang by extending
the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR
instructions (i.e. `CoordinateOpConversion::doRewrite`). The following
case is added:
3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or
`!fir.ref<!fir.type>`).
3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or
`!fir.ptr<!fir.type>`).
From the point of view of the conversion, 3.1 and 3.2 are currently identical.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Originally written by:
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Depends on: D114159
Differential Revision: https://reviews.llvm.org/D115333
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR
instructions.
The following cases are currently supported:
1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or
`!fir.box`)
2. the input object is wrapped in a `!fir.box` (including e.g.
`!fir.array`).
Note that `!fir.complex` inside a `!fir.box` falls under case 1. above
(i.e. it's a special case regardless of the wrapping type).
This is part of the upstreaming effort from the `!fir-dev` branch in [1].
Differential Revision: https://reviews.llvm.org/D114159
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Change dialect (and remove now redundant accessors) to generate both
form of accessors of being generated. Tried to keep this change
reasonably minimal (this also includes keeping note about not generating
getType accessor to avoid shadowing).
Differential Revision: https://reviews.llvm.org/D115420
This patch is part of the upstreaming effort from the fir-dev branch.
Address review comments
- move CHECK blocks to after the mlir code in the test file
- fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace
- fix a few nits
- remove TODO in favor of notifyMatchFailure
- removed unnecessary CHECK line from convert-to-llvm.fir
- rebase on main - add TODO back in
- get successfull test of TODO in AllocMemOp converion of derived type with LEN params
- clearer comments and reduced use of auto
- move defintion of computeDerivedTypeSize to fix build error
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D114104
The XRebox Op is formed by the codegen rewrite which makes it easier to
convert the operation to LLVM. The XRebox op includes the information
from the rebox op and the associated slice, shift, and shape ops.
During the conversion process a new descriptor is created for reboxing.
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D114709
This patch adds the conversion pattern for the fircg.ext_array_coor
operation. It applies the address arithmetic on a dynamically shaped, shifted
and/or sliced array.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D113968
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Convert a fircg.ext_embox operation to LLVM IR dialect.
A fircg.ext_embox is converted to a sequence of operation that
create, allocate if needed, and populate a descriptor.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D114148
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
For unimplemented patterns we revert to using TODO hard failures instead of
notifyMatchFailure.
For fir.select_type revert to using mlir::emiterror.
For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm.
Adding negative tests using not and checking for the error message.
TODO exits with an error in a build without assertion but aborts in a
build with assertions. Abort requires using not with the --crash
option. The two different usages of not is handled by using a custom
command %not_todo_cmd which is converted to not or not --crash
depending on the presence or absence of assertions. Using llvm-config
to check the presence of assertions.
Reviewed By: clementval, awarzynski
Differential Revision: https://reviews.llvm.org/D114371
For unimplemented patterns we revert to using TODO hard failures instead of
notifyMatchFailure.
For fir.select_type revert to using mlir::emiterror.
For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm.
Adding negative tests using not and checking for the error message.
TODO exits with an error in a build without assertion but aborts in a
build with assertions. Abort requires using not with the --crash
option. The two different usages of not is handled by using a custom
command %not_todo_cmd which is converted to not or not --crash
depending on the presence or absence of assertions. Using llvm-config
to check the presence of assertions.
Reviewed By: clementval, awarzynski
Differential Revision: https://reviews.llvm.org/D114371
Also replace ArrayAttr with IndexElementsAttr to model subscript dimensions.
An array of attribute is a sparse inefficient storage, with an API that
requires to unpack/repack integers at every call site.
Instead we can store dense array of integer as IndexElementsAttr.
Reviewed By: clementval, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D112899
This patch is part of the upstreaming effort from fir-dev.
The conversion of len_param_index in fir-dev is incomplete, so for now
we're marking this as unimplemented until we can settle on a design for
the runtime support of LEN parameters.
Differential Revision: https://reviews.llvm.org/D114241
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Currently `fir.no_reassoc` is just removed in the conversion.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D114154
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `fir.field_index` to a sequence of LLVM MLIR
instructions.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D113988
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch extends the FIRToLLVMLowering pass in Flang by adding a hook
to transform fir.end. This is just a placeholder for now as fir.end is
not required yet.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Patch originally written by:
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Differential Revision: https://reviews.llvm.org/D113295
Add the FIR to LLVM conversion patterns for the BoxProcHostOp, EmboxProcOp,
and UnboxProcOp ops and the boxproc type. These are currently unimplemented.
Implementation will come at a later time when support for Fortran 2003
procedure pointer feature is added.
Reviewed By: clementval, rovka
Differential Revision: https://reviews.llvm.org/D113879
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Convert a `fir.embox` operation to LLVM IR dialect.
A `fir.embox` is converted to a sequence of operation that
create, allocate if needed, and populate a descriptor.
Current limitiation: alignment is set by default but should be retrieved in the specific target.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D113756
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Add the codegen for fir.constc.
This patch is part of the upstreaming effort from fir-dev.
Differential Revision: https://reviews.llvm.org/D114063
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds the conversion pattern for
`fir.box_tdes`.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D113931
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
The information in these perations is used by other operation.
At this point they should not have anymore uses.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D113971
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds the conversion pattern for
the fir.string_lit operation.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D113992
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `fir.boxchar_len` to a sequence of LLVM MLIR
instructions.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D113763
Originally written by:
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Jean Perier