[flang][AIX] BIND(C) derived type alignment for AIX (#121505)

This patch is to handle the alignment requirement for the `bind(c)`
derived type component that is real type and larger than 4 bytes. T

[flang][AIX] BIND(C) derived type alignment for AIX (#121505)

This patch is to handle the alignment requirement for the `bind(c)`
derived type component that is real type and larger than 4 bytes. The
alignment of such component is 4-byte.

show more ...

[flang][FIR] remove fir.complex type and its fir.real element type (#111025)

Final patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292

Since

[flang][FIR] remove fir.complex type and its fir.real element type (#111025)

Final patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292

Since fir.real was only still used as fir.complex element type, this
patch removes it at the same time.

show more ...

[flang] Add ability to have special allocator for descriptor data (#100690)

This patch enhances the descriptor with the ability to have specialized
allocator. The allocators are registered in a ded

[flang] Add ability to have special allocator for descriptor data (#100690)

This patch enhances the descriptor with the ability to have specialized
allocator. The allocators are registered in a dedicated registry and the
index of the desired allocator is stored in the descriptor. The default
allocator, std::malloc, is registered at index 0.

In order to have this allocator index in the descriptor, the f18Addendum
field is repurposed to be able to hold the presence flag for the
addendum (lsb) and the allocator index.

Since this is a change in the semantic and name of the 7th field of the
descriptor, the CFI_VERSION is bumped to the date of the initial change.

This patch only adds the ability to have this features as part of the
descriptor but does not add specific allocator yet. CUDA fortran will be
the first user of this feature to allocate descriptor data in the
different type of device memory base on the CUDA attribute.

---------

Co-authored-by: Slava Zakharin <szakharin@nvidia.com>

show more ...

Add basic -mtune support (#98517)

Initial implementation for the -mtune flag in Flang.

This PR is a clean version of PR #96688, which is a re-land of PR #95043

[flang] Remove materialization workaround in type converter (#98743)

This change is in preparation of #97903, which adds extra checks for
materializations: it is now enforced that they produce an S

[flang] Remove materialization workaround in type converter (#98743)

This change is in preparation of #97903, which adds extra checks for
materializations: it is now enforced that they produce an SSA value of
the correct type, so the current workaround no longer works.

The original workaround avoided target materializations by directly
returning the to-be-converted SSA value from the materialization
callback. This can be avoided by initializing the lowering patterns that
insert the materializations without a type converter. For
`cg::XEmboxOp`, the existing workaround that skips
`unrealized_conversion_cast` ops is still in place.

Also remove the lowering pattern for `unrealized_conversion_cast`. This
pattern has no effect because `unrealized_conversion_cast` ops that are
inserted by the dialect conversion framework are never matched by the
pattern driver.

show more ...

mlir/LogicalResult: move into llvm (#97309)

This patch is part of a project to move the Presburger library into
LLVM.

Revert "[flang] Add basic -mtune support" (#96678)

Reverts llvm/llvm-project#95043

[flang] Add basic -mtune support (#95043)

This PR adds -mtune as a valid flang flag and passes the information
through to LLVM IR as an attribute on all functions. No specific
architecture optimiz

[flang] Add basic -mtune support (#95043)

This PR adds -mtune as a valid flang flag and passes the information
through to LLVM IR as an attribute on all functions. No specific
architecture optimizations are added at this time.

show more ...

[flang][debug] Support assumed shape arrays. (#94644)

This PR generates dwarf to extract the information about the arrays from
descriptor. The DWARF needs the offset of the fields like `lower_bound

[flang][debug] Support assumed shape arrays. (#94644)

This PR generates dwarf to extract the information about the arrays from
descriptor. The DWARF needs the offset of the fields like `lower_bound`
and `extent`. The getComponentOffset has been added to calculate
them which pushes the issue of host and target data size into
getDescFieldTypeModel.

As we use data layout now, some tests needed to be adjusted to have a
dummy data layout to avoid failure.

With this change in place, GDB is able show the assumed shape arrays
correctly.

subroutine ff(n, m, arr)
integer n, m
integer :: arr(:, :)
print *, arr
do i = 1, n
do j = 1, m
arr(j, i) = (i * 5) + j + 10
end do
end do
print *, arr
end subroutine ff

Breakpoint 1, ff (n=4, m=3, arr=...) at test1.f90:13
13 print *, arr
(gdb) p arr
$1 = ((6, 7, 8, 9) (11, 12, 13, 14) (16, 17, 18, 19))
(gdb) ptype arr
type = integer (4,3)
(gdb) c
Continuing.
6 7 8 9 11 12 13 14 16 17 18 19

show more ...

[flang][fir] add codegen for fir.load of assumed-rank fir.box (#93569)

- Update LLVM type conversion of assumed-rank fir.box/class to generate
the type of the maximum ranked descriptor. That way, a

[flang][fir] add codegen for fir.load of assumed-rank fir.box (#93569)

- Update LLVM type conversion of assumed-rank fir.box/class to generate
the type of the maximum ranked descriptor. That way, alloca for assumed
rank descriptor copies are always big enough. This is needed in the
fir.load case that generates a new storage for the value
- Add a "computeBoxSize" helper to compute the dynamic size of a
descriptor.
- Use that size to generate an llvm.memcpy intrinsic to copy the input
descriptor into the new storage.

Looking at https://reviews.llvm.org/D108221?id=404635, it seems valid to
add the TBAA node on the memcpy, which I did.

In a further patch, I think we should likely always use a memcpy since
LLVM seems to have a better time optimizing it than fir.load/fir.store
patterns.

show more ...

[flang] Added fir.dummy_scope operation to preserve dummy arguments association. (#90642)

The new operation is just an abstract attribute that is attached to
[hl]fir.declare operations of dummy arg

[flang] Added fir.dummy_scope operation to preserve dummy arguments association. (#90642)

The new operation is just an abstract attribute that is attached to
[hl]fir.declare operations of dummy arguments of a subroutine.
Dummy arguments of the same subroutine refer to the same
fir.dummy_scope, so they can be recognized as such during FIR AliasAnalysis.
Note that the fir.dummy_scope must be specific to the runtime
instantiation of a subroutine, so any MLIR inlining/cloning should duplicate and
unique it vs using the same fir.dummy_scope for different runtime instantiations.
This is why I made it an operation rather than an attribute.
The new operation uses a write effect on DebuggingResource, same as
[hl]fir.declare, to avoid optimizing it away.

show more ...

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change rem

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change removes calls to the deprecated member functions. It does
not mark the functions deprecated yet and does not disable the
deprecation warning in TypeSwitch. This seems to cause problems with
MSVC.

show more ...

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157

show more ...

[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)

See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.

[Flang][Lower] Attach target_cpu and target_features attributes to MLIR functions (#78289)

This patch forwards the target CPU and features information from the
Flang frontend to MLIR func.func oper

[Flang][Lower] Attach target_cpu and target_features attributes to MLIR functions (#78289)

This patch forwards the target CPU and features information from the
Flang frontend to MLIR func.func operation attributes, which are later
used to populate the target_cpu and target_features llvm.func
attributes.

This is achieved in two stages:

1. Introduce the `fir.target_cpu` and `fir.target_features` module
attributes with information from the target machine immediately after
the initial creation of the MLIR module in the lowering bridge.

2. Update the target rewrite flang pass to get this information from the
module and pass it along to all func.func MLIR operations, respectively
as attributes named `target_cpu` and `target_features`. These attributes
will be automatically picked up during Func to LLVM dialect lowering and
used to initialize the corresponding llvm.func named attributes.

The target rewrite and FIR to LLVM lowering passes are updated with the
ability to override these module attributes, and the `CodeGenSpecifics`
optimizer class is augmented to make this information available to
target-specific MLIR transformations.

This completes a full flow by which target CPU and features make it all
the way from compiler options to LLVM IR function attributes.

show more ...

[flang] Lower procedure pointer components (#75453)

Lower procedure pointer components, except in the context of structure
constructor (left TODO).

Procedure pointer components lowering share mo

[flang] Lower procedure pointer components (#75453)

Lower procedure pointer components, except in the context of structure
constructor (left TODO).

Procedure pointer components lowering share most of the lowering logic
of procedure poionters with the following particularities:
- They are components, so an hlfir.designate must be generated to
retrieve the procedure pointer address from its derived type base.
- They may have a PASS argument. While there is no dispatching as with
type bound procedure, special care must be taken to retrieve the derived
type component base in this case since semantics placed it in the
argument list and not in the evaluate::ProcedureDesignator.

These components also bring a new level of recursive MLIR types since a
fir.type may now contain a component with an MLIR function type where
one of the argument is the fir.type itself. This required moving the
"derived type in construction" stackto the converter so that the object
and function type lowering utilities share the same state (currently the
function type utilty would end-up creating a new stack when lowering its
arguments, leading to infinite loops). The BoxedProcedurePass also
needed an update to deal with this recursive aspect.

show more ...

[flang] Add struct passing target rewrite hooks and partial X86-64 impl (#74829)

In the context of C/Fortran interoperability (BIND(C)), it is possible
to give the VALUE attribute to a BIND(C) deri

[flang] Add struct passing target rewrite hooks and partial X86-64 impl (#74829)

In the context of C/Fortran interoperability (BIND(C)), it is possible
to give the VALUE attribute to a BIND(C) derived type dummy, which
according to Fortran 2018 18.3.6 - 2. (4) implies that it must be passed
like the equivalent C structure value. The way C structure value are
passed is ABI dependent.

LLVM does not implement the C struct ABI passing for LLVM aggregate type
arguments. It is up to the front-end, like clang is doing, to split the
struct into registers or pass the struct on the stack (llvm "byval") as
required by the target ABI.
So the logic for C struct passing sits in clang. Using it from flang
requires setting up a lot of clang context and to bridge FIR/MLIR
representation to clang AST representation for function signatures (in
both directions). It is a non trivial task.
See
https://stackoverflow.com/questions/39438033/passing-structs-by-value-in-llvm-ir/75002581#75002581.

Since BIND(C) struct are rather limited as opposed to generic C struct
(e.g. no bit fields). It is easier to provide a limited implementation
of it for the case that matter to Fortran.

This patch:
- Updates the generic target rewrite pass to keep track of both the new
argument type and attributes. The motivation for this is to be able to
tell if a previously marshalled argument is passed in memory (it is a C
pointer), or if it is being passed on the stack (has the byval llvm
attributes).
- Adds an entry point in the target specific codegen to marshal struct
arguments, and use it in the generic target rewrite pass.
- Implements limited support for the X86-64 case. So far, the support
allows telling if a struct must be passed in register or on the stack,
and to deal with the stack case. The register case is left TODO in this
patch.

The X86-64 ABI implemented is the System V ABI for AMD64 version 1.0

show more ...

[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692)

!llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang
codegen still generated them and relied on mli

[flang][codegen] Update FIR codegen to use mlir.llvm opaque pointers (#69692)

!llvm.ptr<T> typed pointers are depreciated in MLIR LLVM dialects. Flang
codegen still generated them and relied on mlir.llvm codegen to LLVM to
turn them into opaque pointers.

This patch update FIR codegen to directly emit and work with LLVM opaque
pointers.

Addresses https://github.com/llvm/llvm-project/issues/69303

- All places generating GEPs need to add an extra type argument with the
base type (the T that was previously in the llvm.ptr<T> of the base).

- llvm.alloca must also be provided the object type. In the process, I
doscovered that we were shamelessly copying all the attribute from
fir.alloca to the llvm.alloca, which makes no sense for the operand
segments. The updated code that cannot take an attribute dictionnary in
the llvm.alloca builder with opaque pointers only propagate the "pinned"
and "bindc_name" attributes to help debugging the generated IR.

- Updating all the places that rely on getting the llvm object type from
lowered llvm.ptr<T> arguments to get it from a type conversion of the
original fir types.

- Updating all the places that were generating llvm.ptr<T> types to
generate the opaque llvm.ptr type.

- Updating all the codegen tests checking generated MLIR llvm dialect.
Many tests are testing directly LLVM IR, and this change is a no-op for
those (which is expected).

show more ...

[flang][driver] add command line arguments for alias tags pass

The ultimate intention is to have this pass enabled by default whenever
we are optimizing for speed. But for now, just add the argument

[flang][driver] add command line arguments for alias tags pass

The ultimate intention is to have this pass enabled by default whenever
we are optimizing for speed. But for now, just add the arguments so this
can be more easily tested.

PR: https://github.com/llvm/llvm-project/pull/68595

show more ...

Remove the `conversionCallStack` from the MLIR TypeConverter

This vector keeps tracks of recursive types through the recursive invocations
of `convertType()`. However this is something only useful f

Remove the `conversionCallStack` from the MLIR TypeConverter

This vector keeps tracks of recursive types through the recursive invocations
of `convertType()`. However this is something only useful for some specific
cases, in which the dedicated conversion callbacks can handle this stack
privately.

This allows removing a mutable member of the type converter.

Reviewed By: springerm

Differential Revision: https://reviews.llvm.org/D158351

show more ...

[mlir][Conversion] Store const type converter in ConversionPattern

ConversionPatterns do not (and should not) modify the type converter that they are using.

* Make `ConversionPattern::typeConverter

[mlir][Conversion] Store const type converter in ConversionPattern

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

show more ...

[mlir][flang] Convert TBAA metadata to an attribute representation

The current representation of TBAA is the very last in-tree user of the `llvm.metadata` operation.
Using ops to model metadata has

[mlir][flang] Convert TBAA metadata to an attribute representation

The current representation of TBAA is the very last in-tree user of the `llvm.metadata` operation.
Using ops to model metadata has a few disadvantages:
* Building a graph has to be done through some weakly typed indirection mechanism such as `SymbolRefAttr`
* Creating the metadata has to be done through a builder within a metadata op.
* It is not multithreading safe as operation insertion into the same block is not thread-safe

This patch therefore converts TBAA metadata into an attribute representation, in a similar manner as it has been done for alias groups and access groups in previous patches.

This additionally has the large benefit of giving us more "correctness by construction" as it makes things like cycles in a TBAA graph, or references to an incorrectly typed metadata node impossible.

Differential Revision: https://reviews.llvm.org/D155444

show more ...

[flang][NFC] Move TypeConverter.h header file to include dir

After the extraction of the TypeConverter, move the header files
to the include dir so the shared library build is fine.

Reviewed By: Pe

[flang][NFC] Move TypeConverter.h header file to include dir

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

show more ...

[flang][NFC] Extract TypeConverter from header file

Extract the type converter definitions into its own .cpp
file so the type converter can be used by passes.

Reviewed By: PeteSteinfeld

Differenti

[flang][NFC] Extract TypeConverter from header file

Extract the type converter definitions into its own .cpp
file so the type converter can be used by passes.

Reviewed By: PeteSteinfeld

Differential Revision: https://reviews.llvm.org/D147824

show more ...