[flang] Use value instead of getValue (NFC)

Flang C++ Style Guide tells us to use x.value() when no presence test
is obviously protecting the reference. Since assert can be disabled,
I don't count

[flang] Use value instead of getValue (NFC)

Flang C++ Style Guide tells us to use x.value() when no presence test
is obviously protecting the reference. Since assert can be disabled,
I don't count it as "protection" here.

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

show more ...

[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] 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] 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][NFC] Cosmetic changes to make the file more homogenous

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

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm

[flang][NFC] Cosmetic changes to make the file more homogenous

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

Reviewed By: jeanPerier

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

show more ...

[flang] Fix bugs relating to support for characters of different kinds

Fix bugs relating to support for characters of different kinds. Lowering
was creating bad FIR and MLIR that crashed in conversi

[flang] Fix bugs relating to support for characters of different kinds

Fix bugs relating to support for characters of different kinds. Lowering
was creating bad FIR and MLIR that crashed in conversion to LLVM IR.

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

Reviewed By: jeanPerier

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

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

show more ...

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

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[flang] Add FIR tests missing from fir-dev

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

Reviewed By: jeanPerier, PeteSteinfeld

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

[flang] Add FIR tests missing from fir-dev

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

Reviewed By: jeanPerier, PeteSteinfeld

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

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

show more ...

[flang] Add more diagnostics to fir.coordinate_of

Add more diagnostics to fir.coordinate_of to provide better checking
that the IR is sane.

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

[flang] Add more diagnostics to fir.coordinate_of

Add more diagnostics to fir.coordinate_of to provide better checking
that the IR is sane.

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

Reviewed By: PeteSteinfeld

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

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

show more ...

Don't use Optional::hasValue (NFC)

[flang] Fix type mismatch in verification error

FIR models Fortran intrinsic types with deliberate KIND values. Like
Fortran, COMPLEX and REAL have related KINDs in FIR. Lowering now
converts REAL t

[flang] Fix type mismatch in verification error

FIR models Fortran intrinsic types with deliberate KIND values. Like
Fortran, COMPLEX and REAL have related KINDs in FIR. Lowering now
converts REAL types to floating point (MLIR) up front. This patch moves
the code to convert from FIR RealType to MLIR FloatType out of codegen
and into the builder, allowing FIR ComplexTypes to have their element
type returned as an MLIR FloatType.

We should consider whether to replace fir::ComplexType with
mlir::ComplexType at some point. I believe these types are presently
used to convey distinctins in the target ABIs in the Tilikum bridge
however.

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

Reviewed By: PeteSteinfeld

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

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

show more ...

[ParseResult] Fix warning in flang build, incorporate feedback from River.

The warning caused build errors on a couple flang testers that are
building with -Werror. The diagnostic change makes the

[ParseResult] Fix warning in flang build, incorporate feedback from River.

The warning caused build errors on a couple flang testers that are
building with -Werror. The diagnostic change makes the generated
error correct.

This is a followup to https://reviews.llvm.org/D125549

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

show more ...

[AsmParser] Introduce a new "Argument" abstraction + supporting logic

MLIR has a common pattern for "arguments" that uses syntax
like `%x : i32 {attrs} loc("sourceloc")` which is implemented
in adho

[AsmParser] Introduce a new "Argument" abstraction + supporting logic

MLIR has a common pattern for "arguments" that uses syntax
like `%x : i32 {attrs} loc("sourceloc")` which is implemented
in adhoc ways throughout the codebase. The approach this uses
is verbose (because it is implemented with parallel arrays) and
inconsistent (e.g. lots of things drop source location info).

Solve this by introducing OpAsmParser::Argument and make addRegion
(which sets up BlockArguments for the region) take it. Convert the
world to propagating this down. This means that we correctly
capture and propagate source location information in a lot more
cases (e.g. see the affine.for testcase example), and it also
simplifies much code.

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

show more ...

[AsmParser] Rework logic around "region argument parsing"

The asm parser had a notional distinction between parsing an
operand (like "%foo" or "%4#3") and parsing a region argument
(which isn't supp

[AsmParser] Rework logic around "region argument parsing"

The asm parser had a notional distinction between parsing an
operand (like "%foo" or "%4#3") and parsing a region argument
(which isn't supposed to allow a result number like #3).

Unfortunately the implementation has two problems:

1) It didn't actually check for the result number and reject
it. parseRegionArgument and parseOperand were identical.
2) It had a lot of machinery built up around it that paralleled
operand parsing. This also was functionally identical, but
also had some subtle differences (e.g. the parseOptional
stuff had a different result type).

I thought about just removing all of this, but decided that the
missing error checking was important, so I reimplemented it with
a `allowResultNumber` flag on parseOperand. This keeps the
codepaths unified and adds the missing error checks.

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

show more ...

[NFC] Sync code for upstreaming.

Remove redundant code.

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

[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace

FuncOp has been moved to the `func` namespace for a little over a month, the
using directive can be dropped now.

[flang] Do not fold fir.box_addr when it has a slice

This patch avoids to fold `fir.box_addr` when the defining `fir.embox` op
has a slice. If the op is folded the slice information are lost.

This

[flang] Do not fold fir.box_addr when it has a slice

This patch avoids to fold `fir.box_addr` when the defining `fir.embox` op
has a slice. If the op is folded the slice information are lost.

This kind of problem occurred with code like:

```
call check(y(half+1:))
```

where `y` is an array.

Reviewed By: jeanPerier

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

show more ...

[mlir] Add support for operation-produced successor arguments in BranchOpInterface

This patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutabl

[mlir] Add support for operation-produced successor arguments in BranchOpInterface

This patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutableSuccessorOperands` for operations, which internally produce arguments to some of the block arguments. A motivating example for this would be an invoke op with a error handling path:
```
invoke %function(%0)
label ^success ^error(%1 : i32)

^error(%e: !error, %arg0 : i32):
...
```
The advantages of this are that any users of `BranchOpInterface` can still argue over remaining block argument operands (such as `%1` in the example above), as well as make use of the modifying capabilities to add more operands, erase an operand etc.

The way this patch implements that functionality is via a new class called `SuccessorOperands`, which is now returned by `getSuccessorOperands`. It basically contains an `unsigned` denoting how many operator produced operands exist, as well as a `MutableOperandRange`, which are the usual forwarded operands we are used to. The produced operands are assumed to the first few block arguments, followed by the forwarded operands afterwards. The role of `SuccessorOperands` is to provide various utility functions to modify and query the successor arguments from a `BranchOpInterface`.

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

show more ...

[mlir] Simplify LoopLikeOpInterface

- Adds default implementations of `isDefinedOutsideOfLoop` and `moveOutOfLoop` since 99% of all implementations of these functions were identical
- `moveOutOfLoop

[mlir] Simplify LoopLikeOpInterface

- Adds default implementations of `isDefinedOutsideOfLoop` and `moveOutOfLoop` since 99% of all implementations of these functions were identical
- `moveOutOfLoop` takes one operation and doesn't return anything anymore. 100% of all implementations of this function would always return `success` and uses would either respond with a pass failure or an `llvm_unreachable`.

show more ...

[flang] Lower boxed procedure

In FIR, we want to wrap function pointers in a special box known as a
boxproc value. Fortran has a limited form of dynamic scoping
[https://tinyurl.com/2p8v2hw7] betwee

[flang] Lower boxed procedure

In FIR, we want to wrap function pointers in a special box known as a
boxproc value. Fortran has a limited form of dynamic scoping
[https://tinyurl.com/2p8v2hw7] between "host procedures" and "internal
procedures". There are a number of implementations possible.

Boxproc typed values abstract away the implementation details of when a
function pointer can be passed directly (as a raw address) and when a
function pointer has to account for the presence of a dynamic scope.
When lowering Fortran syntax to FIR, all function pointers are emboxed
as boxproc values.

When creating LLVM IR, we must strip away the abstraction and produce
low-level LLVM "assembly" code. This patch implements that
transformation as converting the boxproc values to either raw function
pointers or executable trampolines on the stack as needed. The
trampoline then captures the dynamic scope context within an executable
thunk that can be passed instead of the function's raw address.

Some extra handling is required for Fortran functions that return a
character value to deal with LEN values here.

Some of the code in Bridge.cpp and ConvertExpr.cpp and be re-arranged to
faciliate the upstreaming effort.

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

Reviewed By: jeanPerier, PeteSteinfeld

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

Co-authored-by: mleair <[email protected]>
Co-authored-by: Jean Perier <[email protected]>
Co-authored-by: Eric Schweitz <[email protected]>
Co-authored-by: V Donaldson <[email protected]>
Co-authored-by: Kiran Chandramohan <[email protected]>

show more ...

[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`

I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and

[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`

I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and meaning of Type in the context of MLIR, its probably better to rename it. Given the comment in the source code, the suggestion in the GitHub issue and the final discussions in the review, this patch renames the OperandType to UnresolvedOperand.

Fixes https://github.com/llvm/llvm-project/issues/54446

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

show more ...

[flang] Lower procedure designator

This patch adds lowering for procedure designator.

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

Reviewed By: PeteSteinfeld

Differential Rev

[flang] Lower procedure designator

This patch adds lowering for procedure designator.

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

Reviewed By: PeteSteinfeld

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

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

show more ...

[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"

This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes

[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"

This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes it
clear what the intent is (i.e. to represent the type of the function).

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

show more ...