[flang] Use value_or (NFC)

[flang] Use *X instead of X.getValue() (NFC)

Per Flang C++ Style Guide, this patch replaces X.getValue() with *X
where *X is protected by a presence test.

[flang] Merge GEPs in substring fir.embox codegen

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 b

[flang] Merge GEPs in substring fir.embox codegen

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

show more ...

[flang] Use has_value instead of hasValue (NFC)

This patch replaces hasValue with has_value in an effort to deprecate
Optional<X>::hasValue.

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

[flang] Don't use Optional::hasValue (NFC)

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

[flang] Don't use Optional::hasValue (NFC)

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

show more ...

[flang][NFC] Make LEN parameters homogenous

This patch is part of the upstreaming effort from fir-dev branch.
This is the last patch for the upstreaming effort.

Reviewed By: jeanPerier

Differentia

[flang][NFC] Make LEN parameters homogenous

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 <[email protected]>

show more ...

[flang] Avoid opaque pointer issue with character array substring addressing

When addressing a substring of a character array, codegen emits two
GEPs: one for to compute the address of the base elem

[flang] Avoid opaque pointer issue with character array substring addressing

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

show more ...

[flang] Make code more homogenous in CodeGen

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: jeanPerie

[flang] Make code more homogenous in CodeGen

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

show more ...

[flang] Fix lowering issue with character temp

- Add verifiers that determine if an Op requires type parameters or
not and checks that the correct number of parameters is specified.

This patch is

[flang] Fix lowering issue with character temp

- Add verifiers that determine if an Op requires type parameters or
not and checks that the correct number of parameters is specified.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld

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

Co-authored-by: Eric Schweitz <[email protected]>

show more ...

[flang] Lower Fortran math intrinsic operations into MLIR ops or libm calls.

Added new -lower-math-early option that defaults to 'true' that matches
the current math lowering scheme. If set to 'fals

[flang] Lower Fortran math intrinsic operations into MLIR ops or libm calls.

Added new -lower-math-early option that defaults to 'true' that matches
the current math lowering scheme. If set to 'false', the intrinsic math
operations will be lowered to MLIR operations, which should potentially
enable more MLIR optimizations, or libm calls, if there is no corresponding
MLIR operation exists or if "precise" mode is requested.
The generated math MLIR operations are then converted to LLVM dialect
during codegen phase.

The -lower-math-early option is not exposed to users currently. I plan to
get rid of the "early" lowering completely, when "late" lowering
is robust enough to support all math intrinsics that are currently
supported via pgmath. So "late" mode will become default and -lower-math-early
option will not be needed. This will effectively eliminate the mandatory
dependency on pgmath in Fortran lowering, but this is WIP.

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

show more ...

[flang] Restore Optional::value() (NFC)

This patch restores several calls to Optional::value() in preference
to Optional::operator*.

The Flang C++ Style Guide tells us to use x.value() where no pre

[flang] Restore Optional::value() (NFC)

This patch restores several calls to Optional::value() in preference
to Optional::operator*.

The Flang C++ Style Guide tells us to use x.value() where no presence
test is obviously protecting a *x reference to the contents.

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

show more ...

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

Don't use Optional::getValue (NFC)

Don't use Optional::hasValue (NFC)

[Flang] Fixes for XArrayCoorOp

The upstreamed code was not incrementing the sliceOffset in multiples
of 3. This issue is fixed by using Offsets and incrementing by 3 during
every iteration.
In the c

[Flang] Fixes for XArrayCoorOp

The upstreamed code was not incrementing the sliceOffset in multiples
of 3. This issue is fixed by using Offsets and incrementing by 3 during
every iteration.
In the conversion pattern, we were comparing the definingOp of an
operand with an FIR::UndefOp. Use LLVM::UndefOp for conversion.

Reviewed By: clementval, Leporacanthicus

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

show more ...

[flang] Fix bug in character casting. Add missing sext/trunc in code gen.

This patch is part of the upstreaming effort from fir-dev branch.
It also ensures all descriptors created inline complies wi

[flang] Fix bug in character casting. Add missing sext/trunc in code gen.

This patch is part of the upstreaming effort from fir-dev branch.
It also ensures all descriptors created inline complies with LBOUND
requirement that the lower bound is `1` when the related dimension
extent is zero.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier, PeteSteinfeld

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

Co-authored-by: Eric Schweitz <[email protected]>
Co-authored-by: Jean Perier <[email protected]>

show more ...

[flang][NFC] Fix some formatting

Fix some mismatch in format used in the file and reduce the diff with fir-dev
to be able to finish the upstreaming on this file.

This patch is part of the upstreami

[flang][NFC] Fix some formatting

Fix some mismatch in format used in the file and reduce the diff with fir-dev
to be able to finish the upstreaming on this file.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: PeteSteinfeld, kiranchandramohan

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

show more ...

[flang] Fix XArrayCoorOp conversion for index type slices

The previous XArrayCoorOp conversion forgot to change getting the
operands from OpAdaptor for upper bound and step of slice. This leads to
t

[flang] Fix XArrayCoorOp conversion for index type slices

The previous XArrayCoorOp conversion forgot to change getting the
operands from OpAdaptor for upper bound and step of slice. This leads to
the fail of incompatible of types of codegen when slices are index type.

Reviewed By: kiranchandramohan, schweitz

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

show more ...

[flang] Fix AllocaOp/AllocMemOp type conversion

For arrays without a constant interior or arrays of character with
dynamic length arrays, the data types are converted to a pointer to the
element typ

[flang] Fix AllocaOp/AllocMemOp type conversion

For arrays without a constant interior or arrays of character with
dynamic length arrays, the data types are converted to a pointer to the
element type, so the scale size of the constant extents needs to be
counted. The previous AllocaOp conversion does not consider the arrays
of character with dynamic length arrays, and the previous AllocMemOp
conversion does not consider arrays without a constant interior. This
fixes them and refactors the code so that it can be shared. Also add
the test cases.

Reviewed By: Jean Perier

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

show more ...

[NFC] More synching of sources for upstreaming.

Reviewed By: clementval

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

Added lowering support for atomic read and write constructs

This patch adds lowering support for atomic read and write constructs.
Also added is pointer modelling code to allow FIR pointer like type

Added lowering support for atomic read and write constructs

This patch adds lowering support for atomic read and write constructs.
Also added is pointer modelling code to allow FIR pointer like types to
be inferred and converted while lowering.

Reviewed By: kiranchandramohan

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

Co-authored-by: Kiran Chandramohan <[email protected]>

show more ...

[flang] Fix fir.embox codegen with constant interior shape

Fix https://github.com/flang-compiler/f18-llvm-project/issues/1416.

The `constRows` variable was being decremented too soon, causing the
l

[flang] Fix fir.embox codegen with constant interior shape

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

show more ...

[flang] Set lower bounds of array section fir.embox to one

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

[flang] Set lower bounds of array section fir.embox to one

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

show more ...

[mlir] Rework the implementation of TypeID

This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implici

[mlir] Rework the implementation of TypeID

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

show more ...