[mlir][IR] Remove factory methods from `FloatType` (#123026)

This commit removes convenience methods from `FloatType` to make it
independent of concrete interface implementations.

See discussion

[mlir][IR] Remove factory methods from `FloatType` (#123026)

This commit removes convenience methods from `FloatType` to make it
independent of concrete interface implementations.

See discussion here:
https://discourse.llvm.org/t/rethink-on-approach-to-low-precision-fp-types/82361

Note for LLVM integration: Replace `FloatType::getF32(` with
`Float32Type::get(` etc.

show more ...

[flang] AArch64 ABI for BIND(C) VALUE parameters (#118305)

This patch adds handling for derived type VALUE parameters in BIND(C)
functions for AArch64.

[flang][fir] fix ABI bug 116844 (#118121)

Fix issue #116844.

The issue came from a look-up on the func.func for the sret attribute
when lowering fir.call with character arguments. This was broke

[flang][fir] fix ABI bug 116844 (#118121)

Fix issue #116844.

The issue came from a look-up on the func.func for the sret attribute
when lowering fir.call with character arguments. This was broken because
the func.func may or may not have been rewritten when dealing with the
fir.call, but the lookup assumed it had not been rewritten yet. If the
func.func was rewritten and the result moved to a sret argument, the
call was lowered as if the character was meant to be the result, leading
to bad call code and an assert.

It turns out that the whole logic is actually useless since fir.boxchar
are never lowered as sret arguments, instead, lowering directly breaks
the character result into the first two `fir.ref<>, i64` arguments. So,
the sret case was actually never used, except in this bug.

Hence, instead of fixing the logic (probably by looking for argument
attributes on the call itself), just remove this logic that brings
unnecessary complexity.

show more ...

[Flang] LoongArch64 support for BIND(C) derived types in mabi=lp64d. (#117108)

This patch:
- Supports both the passing and returning of BIND(C) type parameters.
- Adds `mabi` check for LoongArch64

[Flang] LoongArch64 support for BIND(C) derived types in mabi=lp64d. (#117108)

This patch:
- Supports both the passing and returning of BIND(C) type parameters.
- Adds `mabi` check for LoongArch64. Currently, flang only supports
`mabi=` option
set to `lp64d` in LoongArch64, other ABIs will report an error and may
be supported
in the future.

Reference ABI:

https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#subroutine-calling-sequence

show more ...

[flang] AArch64 support for BIND(C) derived return types (#114051)

This patch adds support for BIND(C) derived types as return values
matching the AArch64 Procedure Call Standard for C.

Support

[flang] AArch64 support for BIND(C) derived return types (#114051)

This patch adds support for BIND(C) derived types as return values
matching the AArch64 Procedure Call Standard for C.

Support for BIND(C) derived types as value parameters will be in a
separate patch.

show more ...

[Flang][LoongArch] Add sign extension for i32 arguments and returns in function signatures. (#116146)

In loongarch64 LP64D ABI, `unsigned 32-bit` types, such as unsigned int,
are stored in general-

[Flang][LoongArch] Add sign extension for i32 arguments and returns in function signatures. (#116146)

In loongarch64 LP64D ABI, `unsigned 32-bit` types, such as unsigned int,
are stored in general-purpose registers as proper sign extensions of
their 32-bit values. Therefore, Flang also follows it if a function
needs to be interoperable with C.

Reference:

https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#Fundamental-types

show more ...

[Flang][LoongArch] Add support for complex16 params/returns. (#114732)

In LoongArch64, the passing and returning of type `complex16` is similar
to that of structure type like `struct {fp128, fp128}

[Flang][LoongArch] Add support for complex16 params/returns. (#114732)

In LoongArch64, the passing and returning of type `complex16` is similar
to that of structure type like `struct {fp128, fp128}`, meaning they are
passed and returned by reference. This behavior is similar to clang, so
it can implement conveniently `iso_c_binding`.

Additionally, this patch fixes the failure in flang test
Integration/debug-complex-1.f90:
```
llvm-project/flang/lib/Optimizer/codeGen/Target.cpp:56:
not yet implemented: complex for this precision for return type

show more ...

[flang] correctly deal with bind(c) derived type result ABI (#111969)

Derived type results of BIND(C) function should be returned according
the the C ABI for returning the related C struct type.

[flang] correctly deal with bind(c) derived type result ABI (#111969)

Derived type results of BIND(C) function should be returned according
the the C ABI for returning the related C struct type.

This currently did not happen since the abstract-result pass was forcing
the Fortran ABI for all derived type results.
use the bind_c attribute that was added on call/func/dispatch in FIR to
prevent such rewrite in the abstract result pass, and update the
target-rewrite pass to deal with the struct return ABI.

So far, the target specific part of the target-rewrite is only
implemented for X86-64 according to the "System V Application Binary
Interface AMD64 v1", the other targets will hit a TODO, just like for
BIND(C), VALUE derived type arguments.

This intends to deal with #102113.

This is a re-land of #111678 with an extra commit to keep rewriting `type(c_ptr)`
results to `!fir.ref<none>` in the abstract result pass regardless of the ABIs.

show more ...

Revert "[flang] correctly deal with bind(c) derived type result ABI" (#111858)

Reverts llvm/llvm-project#111678

Causes ARM failure in test suite. TYPE(C_PTR) result should not regress
even if st

Revert "[flang] correctly deal with bind(c) derived type result ABI" (#111858)

Reverts llvm/llvm-project#111678

Causes ARM failure in test suite. TYPE(C_PTR) result should not regress
even if struct ABI no implemented for the target.
https://lab.llvm.org/buildbot/#/builders/143/builds/2731
I need to revisit this.

show more ...

[flang] correctly deal with bind(c) derived type result ABI (#111678)

Derived type results of BIND(C) function should be returned according
the the C ABI for returning the related C struct type.

[flang] correctly deal with bind(c) derived type result ABI (#111678)

Derived type results of BIND(C) function should be returned according
the the C ABI for returning the related C struct type.

This currently did not happen since the abstract-result pass was forcing
the Fortran ABI for all derived type results.
use the bind_c attribute that was added on call/func/dispatch in FIR to
prevent such rewrite in the abstract result pass, and update the
target-rewrite pass to deal with the struct return ABI.

So far, the target specific part of the target-rewrite is only
implemented for X86-64 according to the "System V Application Binary
Interface AMD64 v1", the other targets will hit a TODO, just like for
BIND(C), VALUE derived type arguments.

This intends to deal with
https://github.com/llvm/llvm-project/issues/102113.

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] replace fir.complex usages with mlir complex (#110850)

Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last s

[flang] replace fir.complex usages with mlir complex (#110850)

Core patch of
https://discourse.llvm.org/t/rfc-flang-replace-usages-of-fir-complex-by-mlir-complex-type/82292.
After that, the last step is to remove fir.complex from FIR types.

show more ...

[flang][debug] Support derived types. (#99476)

This PR adds initial debug support for derived type. It handles
`RecordType` and generates appropriate `DICompositeTypeAttr`. The
`TypeInfoOp` is use

[flang][debug] Support derived types. (#99476)

This PR adds initial debug support for derived type. It handles
`RecordType` and generates appropriate `DICompositeTypeAttr`. The
`TypeInfoOp` is used to get information about the parent and location of
the derived type.

We use `getTypeSizeAndAlignment` to get the size and alignment of the
components of the derived types. This function needed a few changes to
be suitable to be used here:

1. The `getTypeSizeAndAlignment` errored out on unsupported type which
would not work with incremental way we are building debug support. A new
variant of this function has been that returns an std::optional. The original
function has been renamed to `getTypeSizeAndAlignmentOrCrash` as it
will call `TODO()` for unsupported types.

2. The Character type was returning size of just element and not the
whole string which has been fixed.

The testcase checks for offsets of the components which had to be
hardcoded in the test. So the testcase is currently enabled on x86_64.

With this PR in place, this is how the debugging of derived types look
like:

```
type :: t_date
integer :: year, month, day
end type

type :: t_address
integer :: house_number
end type
type, extends(t_address) :: t_person
character(len=20) name
end type
type, extends(t_person) :: t_employee
type(t_date) :: hired_date
real :: monthly_salary
end type
type(t_employee) :: employee

(gdb) p employee
$1 = ( t_person = ( t_address = ( house_number = 1 ), name = 'John', ' ' <repeats 16 times> ), hired_date = ( year = 2020, month = 1, day = 20 ), monthly_salary = 3.1400001 )
```

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

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 ...

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][AArch64] Add support for complex16 params/returns (#84217)

Fixes #84088

[flang] Resolve "possible performance problem" issue spam (#79769)

Four "issues" on GitHub report possible performance problems, likely
detected by static analysis. None of them would ever make a m

[flang] Resolve "possible performance problem" issue spam (#79769)

Four "issues" on GitHub report possible performance problems, likely
detected by static analysis. None of them would ever make a measureable
difference in compilation time, but I'm resolving them to clean up the
open issues list.

Fixes https://github.com/llvm/llvm-project/issues/79703, .../79705,
.../79706, & .../79707.

show more ...

[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] Use DataLayout for computing type size in LoopVersioning. (#79778)

The existing type size computation in LoopVersioning does not work
for REAL*10, because the compute element size is 10 byt

[flang] Use DataLayout for computing type size in LoopVersioning. (#79778)

The existing type size computation in LoopVersioning does not work
for REAL*10, because the compute element size is 10 bytes,
which violates the power-of-two assertion.
We'd better use the DataLayout for computing the storage size
of each element of an array of the given type.

show more ...

[flang] finish BIND(C) VALUE derived type passing ABI on X86-64 (#77742)

Derived type passed with VALUE in BIND(C) context must be passed like C
struct and LLVM is not implementing the ABI for this

[flang] finish BIND(C) VALUE derived type passing ABI on X86-64 (#77742)

Derived type passed with VALUE in BIND(C) context must be passed like C
struct and LLVM is not implementing the ABI for this (it is up to the
frontends like clang).

Previous patch #75802 implemented the simple cases where the derived
type have one field, this patch implements the general case. Note that
the generated LLVM IR is compliant from a X86-64 C ABI point of view and
compatible with clang generated assembly, but that it is not guaranteed
to match the LLVM IR signatures generated by clang for the C equivalent
functions because several LLVM IR signatures may lead to the same X86-64
signature.

show more ...

[flang] Pass one element struct by register on X86-64 (#75802)

Implement the C struct passing ABI on X86-64 for the trivial case where
the structs have one element. This is required to cover some c

[flang] Pass one element struct by register on X86-64 (#75802)

Implement the C struct passing ABI on X86-64 for the trivial case where
the structs have one element. This is required to cover some cases of
BIND(C) derived type pass with the VALUE attribute.

show more ...