When an array element is extracted from an unlimited polymorphic array, the
emboxing of this element has to retrive the type code and element size from
the initial array. This patch retrive this information through the extracted
type descriptor.
This situation can be found in code like:
```
subroutine sub1(a)
class(*) :: a(:)
select type (x=>a(1))
type is (integer)
x = 10
end select
end subroutine
```
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141274
This is part of an effort to migrate from llvm::Optional to
std::optional. This patch changes the way mlir-tblgen generates .inc
files, and modifies tests and documentation appropriately. It is a "no
compromises" patch, and doesn't leave the user with an unpleasant mix of
llvm::Optional and std::optional.
A non-trivial change has been made to ControlFlowInterfaces to split one
constructor into two, relating to a build failure on Windows.
See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D138934
Exponentiation is lowered to either math::FPowI or Fortran runtime
call (in case of --math-runtime=precise).
MathToFuncs convertor will convert math::FPowI operations with
exponent width >32 to calls of outlined implementations and otherwise
will leave the operation to MathToLLVM convertor.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139806
Power functions are implemented as linkonce_odr scalar functions
for FPowI operations met in a module.
Vector form of FPowI is linearized into a sequence of calls
of the scalar functions.
Option {min-width-of-fpowi-exponent} controls which FPowI operations
are converted by MathToFuncs: if the width of the exponent's integer
type is less than the specified value, then the operation is not converted.
Flang will specify {min-width-of-fpowi-exponent=33} to make sure that
math::FPowI operations with exponent wider than 32 bits will be converted
by MathToFuncs, and operations with more narrow exponent will be left
for MathToLLVM to convert them to LLVM::PowIOp.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D139804
When emboxing an entity to a polymorphic box, use the input type to
compute the type code and element size as the box type is too generic.
When reboxing a polymorphic box, get this information from the input
box.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139916
The verifier of fir.emboxchar accepts `fir.char<kind, constant>` types,
but its codegen failed because of a missing cast. It is convenient and
safe to not require making the cast in FIR, so add it in codegen.
Differential Revision: https://reviews.llvm.org/D139514
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Record type was not correctly retrived so the runtime call was not
produced correctly.
Fix how the record type is retrived so the correct call is
produced.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D139084
Change how the binding tables are retrived. Use the newly lowered
fir.dispatch_table operations instead of the fir.global type infos.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138903
Code generation to create and populate the descriptor (element size and
type code) is based on the boxed result type. This does not work well with
unlimited polymorphic entities since the fir type does not represent what is
actually emboxed or reboxed.
In the case of emboxing, the input type will be used to populate
the descriptor element size and type code.
When reboxing an unlimited polymorphic to a unlimited polymorphic entities, the
element size and type code is retrieve from the input box.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D138587
Initialization of unlimited polymorphic descriptor was raising an error.
This patch sets a default size and type code for unlimited polymoprhic descriptor
that will be updated once allocated/assigned.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D138479
Couple of operation are expecting BoxType but can totally handle
ClassType as well. This patch updates couple of locations to support
BaseBoxType instead of BoxType only.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D138422
Create the fir.dispatch_table operation based on semantics
information. The fir.dispatch_table will be used for static devirtualization
as well as for fir.select_type conversion.
Depends on D138129
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D138131
`fir.box_typecode` operation allows to retrieve the type code
from a boxed value. This will be used in the `fir.select_type` conversion
to if-then-else ladder for type guard statement with intrinsic type spec
instead of using a runtime call.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D137829
The main purpose of this patch is to propagate fastmath attribute
to SimplifyIntrinsicsPass, so that the inline code can inherit
the call operation's attributes. Even though I added translation
of fastmath from fir::CallOp to LLVM::CallOp, there are no fastmath
attributes in LLVM IR. It looks like the translation drops it.
This will need additional commits.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D137602
When a fir.dispatch is done with a NOPASS type-bound
procedure, the object in fir.dispatch is just used to gather the vtable.
Therefore, no transformation is done on it and the original entity
is used. The current code generation didn't expect the entity to be an array.
This patch update the code generation to be able to retrieve the vtable
accordingly.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137255
This patch fix issues found during call to deallocate.
fir.class can be handled the same way as fir.box in fir.store operation
code generation. In MutableBox::createNewFirBox, the fir.class is
also already a boxed entity.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D137079
Lowering of allocate statement for polymoprhic pointers is a bit
different than for allocatables. A call to `PointerNullifyDerived`
runtime function is done instead of `AllocatableInitDerived`.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D136820
This patch lowers the complex operations supported by the MLIR complex
dialect to those operations rather than libm. When the math runtime flag
is set to precise, libm lowering is used instead.
Differential Revision: https://reviews.llvm.org/D135882
For polymoprhic entities, the type descriptor is dynamic. The tdesc
operand on fir.embox is meant to propagate the dynamic type when
embox a polymorphic entity.
This patch makes use of this operand in code generation and update
the created descriptor accordingly.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136748
Load the pointer of the dynamic type descriptor from the
original box and update the destination descriptor with this pointer.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D136618
fir.dispatch code generation was not handling fir.class pointer and
allocatable types. Update the code generation part to rertieve correctly the
the type info from those types.
Depends on D136426
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136429
When allocating a polymorphic entity, its type descriptor can come
from the declared type or can be provided in the allocate statement.
This patch adds lowering for allocate on polymorphic by calling
the `AllocatableInitDerived` runtime function with the correct
type descriptor. Some adaptation are made in the code generation
to accept fir.class where it is appropriate.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136426
The single precision `hypot` intrinsic is lowered to a call to the libm
`hypotf` function. However, the MSVC runtime lacks a hypotf function
and instead uses `_hypotf` (*). This patch tries to find and rewrite
calls to `hypotf` if we're on a MSVC platform.
Calls to libm functions can be introduced even after lowering (**).
Therefore, we try to do the rewriting at the very end of FIR to LLVM
lowering.
Fixes https://github.com/llvm/llvm-project/issues/57563
(*) More specifically, MSVC's headers define hypotf as an inline
function that just calls _hypotf. This works fine for clang, since it
will include those headers, but flang only links with the CRT so we
don't get a free ride.
(**) 56f94ede2a/flang/lib/Optimizer/CodeGen/CodeGen.cpp (L3391)
Differential Revision: https://reviews.llvm.org/D135853
fir.dispatch code generation uses the binding table stored in the
type descriptor. There is no runtime call involved. The binding table
is always build from the parent type so the index of a specific binding
is the same in the parent derived-type or in the extended type.
Follow-up patches will deal cases not present here such as allocatable
polymorphic entities or pointers.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D136189
Binding tables are needed to perform the fir.dispatch code generation.
The binding tables are defined as fir.global from the initial lowering.
This patch adds the ability to reconstruct the binding tables information
and store the procedure name and binding index for later use by the
fir.dispatch code generation.
Tests will come with follow up patch that makes full use of this information.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D136141
`fir.box` and `fir.ref<fir.box>` are both lowered to LLVM as a
descriptor in memory. This is because fir.box of polymorphic and assumed
rank entities cannot be known at compile time, so fir.box cannot be
lowered to a struct value.
fir.load or fir.ref<fir.box> was previously lowered to a no-op,
propagating the operand descriptor storage as a result.
This is wrong because the operand descriptor storage may later be
modified, and these changes should not be visible in the loaded fir.box
that is an immutable SSA value.
Modify fir.load codegen for fir.box to make a copy into a new storage to
ensure the fir.box is immutable.
Differential Revision: https://reviews.llvm.org/D133779
This change makes sure that we compute the element size and the byte stride
based on the target representation of the element type.
For example, when REAL*10 is mapped to x86_fp80 each element occupies
16 bytes rather than 10 because of the padding.
Note that the size computation method used here actually returns
the distance between two adjacent element of the *same* type in memory
(which is equivalent to llvm::DataLayout::getTypeAllocSize()).
It does not return the number of bytes that may be overwritten
by storing a value of the specified type (e.g. what can be computed
via llvm::DataLayout::getTypeStoreSize(), but not available in
mlir::DataLayout).
Differential Revision: https://reviews.llvm.org/D133508
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.
Reviewed By: mehdi_amini, rriddle
Differential Review: https://reviews.llvm.org/D132838
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.
Reviewed By: mehdi_amini, rriddle
Differential Review: https://reviews.llvm.org/D132838
This patch "modernizes" the LLVM `insertvalue` and `extractvalue`
operations to use DenseI64ArrayAttr, since they only require an array of
indices and previously there was confusion about whether to use i32 or
i64 arrays, and to use assembly format.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131537
GCC and that specific build bot issued warnings turned errors, due to a narrowing conversion from `unsigned` to `int32_t`. Silence these via a static_cast.
This is the follow up on https://reviews.llvm.org/D130730 which goes through upstream code and removes creating constant values in favour of using the constant indices in GEP directly. This leads to less and more readable code and more compact IR as well.
Differential Revision: https://reviews.llvm.org/D130731
When an array is defined with "unknown" size, such as fir.array<2x?x5xi32>,
it should be converted to llvm.array<10 x i32>. The code so far has
been converting it to llvm.ptr<i32>.
Using a different function to check the if there starting are constant
dimensions, rather than if ALL dimensions are constant, it now produces
the correct array form.
Some tests has been updated, so they are now checking the new behaviour
rather than the old behaviour - so there's no need to add further tests
for this particular scenario.
This was originally found when compiling Spec 17 code, where an assert
in a GepOP was hit. That is bug #56141, which this change fixes.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D129196
When computing the base addresses of an array slice to make a
descriptor, codegen generated two LLVM GEPs. The first to compute
the address of the base character element, and a second one to
compute the substring base inside that element.
The previous code did not care about getting the result of the first
GEP right: it used the base array LLVM type as the result type.
This used to work when opaque pointer were not enabled (the actual GEP
result type was probably applied in some later pass). But with opaque
pointers, the second GEP ends-up computing an offset of len*<LLVM array
type> instead of len*<character width>. A previous attempt to fix the
issue was done in D129079, but it does not cover the cases where the
array slice contains subcomponents before the substring
(e.g: array(:)%char_field(5:10)).
This patch fix the issue by computing the actual GEP result type in
codegen. There is also enough knowledge now so that a single GEP can be
generated instead of two.
Differential Revision: https://reviews.llvm.org/D129481
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
This patch is part of the upstreaming effort from fir-dev branch.
This is the last patch for the upstreaming effort.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D129187
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
When addressing a substring of a character array, codegen emits two
GEPs: one for to compute the address of the base element, and a second
one to address the first characters from that element.
The first GEP still returns the LLVM array type (if the FIR array type could be
translated to an array type. Therefore) so zero
indexes must be added to the second GEP in this case to cover for the
Fortran array dimensions before inserting the susbtring offset index.
Surprisingly, the previous code worked ok when MLIR emits none opaque
pointers. But with opaque pointers, the two GEPs are folded in an
invalid GEP where the substring offset becomes an offset for the outer
array dimension.
Note that I tried to fix the issue by modifying the first GEP to return the
element type, but this still gave bad results (here something might be
wrong with opaque pointer in MLIR or LLVM).
Differential Revision: https://reviews.llvm.org/D129079
This patch just make the code more similar
in each conversion.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D129071
