ConversionPatterns do not (and should not) modify the type converter that they are using.
* Make `ConversionPattern::typeConverter` const.
* Make member functions of the `LLVMTypeConverter` const.
* Conversion patterns take a const type converter.
* Various helper functions (that are called from patterns) now also take a const type converter.
Differential Revision: https://reviews.llvm.org/D157601
For character type with unknown length we end up generating
a GEP with the base type `llvm.ptr<i[width]>`. The GEP produces
the address of the first element of the slice, and it should be
using the offset computed in the number of characters, while we were
providing the offset in bytes.
Simple reproducer fails with and w/o HLFIR:
```
program test
integer,parameter :: ck = 4
character(:,ck),allocatable :: res(:,:)
allocate(character(3,ck) :: res(2,2))
res(1,1) = ck_'111'
res(1,2) = ck_'222'
res(2,1) = ck_'333'
res(2,2) = ck_'444'
call check(res)
contains
subroutine check(res)
character(:,ck),allocatable :: res(:,:)
print *, res(2,:)
end subroutine check
end program test
```
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D156849
Identify multidimensional array indices in subcomponents and
convert them from column-major to row-major ordering.
This fixes codegen for fircg.ext_array_coor, fircg.ext_embox and,
possibly, fircg.ext_rebox.
Fixes https://github.com/llvm/llvm-project/issues/62038
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D154214
The code generation of the fir.embox op creating descriptors for
array substring with a non constant length base was using the
substring length to compute the first dimension result stride.
Fix it to use the input length instead.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D154086
fir.rebox is emitting an llvm.sdiv to compute the character length
given the byte size from the input descriptor.
Inside a fir.global, this is not needed given the target length must
be accessible via the type, and it caused MLIR to fail LLVM IR
code generation (and crash).
Use the input type length when available instead.
Reviewed By: PeteSteinfeld, vzakhari
Differential Revision: https://reviews.llvm.org/D154072
On platforms which support COMDAT sections we should use them when
linkonce or linkonce_odr linkage is requested. This is required on
Windows (PE/COFF) and provides better behaviour than weak symbols on
ELF-based platforms.
This patch also reverts string literals to use linkonce instead of
internal linkage now that comdats are supported.
Differential Revision: https://reviews.llvm.org/D153768
The information needed for translation is now encoded in the dialect
operations and does not require a dedicated pass to be extracted.
Remove the obsolete passes that were performing operand legalization.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D150248
Instead of filling uninitialized global variables with "undef",
initialize them with 0. Only for Integer, Float or Logical type
variables. Complex, user defined data structures, arrays, etc
are not supported at this point.
This patch fixes the main problem of
https://github.com/llvm/llvm-project/issues/62432
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D149877
Fir.GlobalOp's currently do not respect attributes that
are applied to them, this change will do two things:
- Allow lowering of arbitrary attributes applied to
Fir.GlobalOp's to LLVMGlobalOp's during CodeGen
- Allow printing and parsing of arbitrarily applied attributes
This allows applying other dialects attributes (or other
fir attributes) to fir.GlobalOps on the fly and have them
exist in the resulting LLVM dialect IR or FIR IR.
Reviewer: jeanPerier
Differential Revision: https://reviews.llvm.org/D148352
The code was using the original operand of the operation, while
it should have been using the remapped operands via the adaptor.
Differential Revision: https://reviews.llvm.org/D148587
When dealing with "derived_array(j)%component" where derived_array
is not a contiguous array, but for which we know the extent, lowering
generates a fir.array_coor op on a !fir.box<!fir.array<cst x T>> with
a fir.slice containing "j" in the component path.
Codegen first computes "derived_array(j)" address using the byte
strides inside the descriptor, and then computes the offset of "j"
from that address with a second GEP.
The type of the address in that second GEP matters since "j" is passed
in the GEP via an index indicating its component position in the type.
The code was using the LLVM type of "derived_array" instead of
"derived_array(j)".
In general, with fir.box, the extent ("cst" above) is unknown and those
types match. But if the extent of "derived_array" is a compile time
constant, its LLVM type will be [cst x T] instead of T*, and the produced
GEP will compute the address of the nth T instead of the nth component
inside T leading to undefined behaviors.
Fix this by computing the element type for the second GEP.
Differential Revision: https://reviews.llvm.org/D148226
After the extraction of the TypeConverter, move the header files
to the include dir so the shared library build is fine.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D147979
Currently `fir.divc` is always lowered to a sequence of llvm operations to perform complex division, however this causes issues for extreme values when the calculations overflow. While this behaviour would be fine at -Ofast, this is currently the default at all levels.
This patch changes `fir.divc` to lower to a library call instead, except for when KIND=3 as there is no appropriate library call for this case.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D145808
Flang was missing value normalization for logical<->integer conversions
which is required by Flang specification. The shrinking logical<->logical
conversions were also incorrectly truncating the input.
This change performs value normalization for all logical<->integer
conversions and logical<->logical conversions between different kinds.
Note that value normalization is not strictly required for
logical(kind=k1)->logical(kind=k2) conversions when k1 < k2.
Differential Revision: https://reviews.llvm.org/D147019
CodeGen used llvm.sext when converting fir.convert %0 : (i1) -> iXX
where iXX is any integer. This leads to wrong values when the initial
i1 is equal to 1.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D145984
This revision uses the AliasAnalysisOpInterface introduced in
https://reviews.llvm.org/D144851 to set the tbaa attributes
of load and store ops. With the attribute it is also possible to
set the attribute on atomics as well as on memcopy and
memove intrinsics as soon as https://reviews.llvm.org/D144965
lands.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D145044
We used to specify benefit=0 for MathToLibm patterns so that
MathToLLVM patterns are more preferable. D144450 removed
the benefit parameter, so we have to run MathToLLVM separately now.
This resolves Intrinsics/math-codegen failure caused by D144450.
Differential Revision: https://reviews.llvm.org/D144523
Makes use of fir.type_desc in order to delay the type desc address
resolution. The lowering inserts fir.type_desc operation instead of fir.addr_of
operation pointing to the fir.global type descriptor. The fir.type_desc
operation is then lowered in code gen to an address of operation in the LLVM
dialect. At this stage, the type descriptor is generated in all cases.
Reviewed By: vdonaldson
Differential Revision: https://reviews.llvm.org/D142920
When emboxing to a polymorphic entity without a type source box,
the type desc address must be retrived from the input type and
not from the box type.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D142435
When a `!fir.box<>` is passed as an actual argument to an optional
`!fir.class<>` dummy it needs a `fir.rebox` in order to propagate
the dynamic type information.
The `fir.rebox` needs to happen only on present argument.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D142340
This is initial version of TBAA information generation for Flang
generated IR. The desired behavior is that TBAA type descriptors
are generated for FIR types during FIR to LLVM types conversion,
and then TBAA access tags are attached to memory accessing operations
when they are converted to LLVM IR dialect.
In the initial version the type conversion is not producing
TBAA type descriptors, and all memory accesses are just partitioned
into two sets of box and non-box accesses, which can never alias.
The TBAA generation is enabled by default at >O0 optimization levels.
TBAA generation may also be enabled via `apply-tbaa` option of
`fir-to-llvm-ir` conversion pass. `-mllvm -disable-tbaa` engineering
option allows disabling TBAA generation to override Flang's default
(e.g. when -O1 is used).
SPEC CPU2006/437.leslie3d speeds up by more than 2x on Icelake.
Reviewed By: jeanPerier, clementval
Differential Revision: https://reviews.llvm.org/D141820
When creating temporary from a polymorphic entity, its dynamic type
information must be carried over to the temporary.
This patch updates createTempMutableBox to support passing a source_box
from which the information will be carried over.
This is tested on the spread intrinsic and follow-up patches will updates
other temporary creation where needed.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141667
Until now, only the address of the type descriptor was hold in
a PolymorphicValue. In some cases, the element size and the
type code are also needed when creating new polymorphic
descriptors from an element of a polymorphic entity.
This patch updates PolymorphicValue to carry the source
descriptor from which the element is extracted. The source
descriptor is then used when emboxing the element to a new
polymorphic descriptor.
This simplify the code done in D141274 and will be used
when creating polymorphic temporary as well.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141609
Unlimited polymorphic descriptor have a set size and can be loaded the
same way as polymorphic or monomorphic descriptors. The descriptor
code gen as been set in D138587.
Of course, the data hold by those descriptors have an unknown size
at compile time.
Depends on D141383
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D141390
The current lowering of initial target in fir.global is relying
on how fir.box are created: instead of using a fir.rebox to add
the POINTER attribute to the created descriptor, it is looking
for a fir.embox defining operation and creating a copy of
it with a different result types.
The rational for doing so was that fir.rebox codegen was not possible
inside fir.global because it expects to manipulate the input fir.box
in memory, while objects cannot be manipulated in memory inside
a fir.global region that must be constant foldable.
But this approach has two problems:
- it won't work with hlfir where fir.box may be created by more
operations than fir.embox (e.g. hlfir.delcare or hlfir.designate).
In general, looking for a precise defining op for a value is
fragile.
- manually copying and modifying an operation is risky: it is easy
to forget copying some default operands (that could be added later).
This patch modifies the helpers to get descriptor fields so that they
can both operate on fir.box lowered in memory or in an llvm.struct
value. This enables the usage of fir.rebox in fir.global op.
The fallout in FIR tests is caused by the usage of constant index
when creating GEP (because extractOp requires constant indices).
MLIR builder uses i32 bit constant indices when non mlir::Value
indices are passed to the MLIR GEP op builder. Previously,
an 64 nist mlir constant value was created and passed to the GEP
builder. In this case, the builder respect the value type when
later generating the GEP.
Given this changes impact the "dimension" index that can, per
Fortran requirement, not be greated than 15, using a 32 bit index
is just fine and actually simplify the MLIR LLVM IR generation.
The fallout in lowering tests is caused by the introduction
of the fir.rebox everytime an initial target is created.
Differential Revision: https://reviews.llvm.org/D141136
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
