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 <kiran.chandramohan@arm.com>
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
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
- 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`.
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 <leairmark@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
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
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 <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds lowering to suppoert statement functions
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121990
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
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
Allow fir.rebox input and output element type to differ for characters
if:
- Any of the character type is dynamic. Fortran allows making pointer
assignments between deferred and constant lengths entities, making this
case useful (if the input length is dynamic and the output length constant,
it is a user requirement that the length matches at runtime. There is no
option to check this at runtime, but it could be added as an option to
fir.rebox codegen later if desired).
- Or, there is a slice in the fir.rebox (the fir.rebox can implement a
substring view, hence the constant output and input lengths).
This is only a verifier constraint change, the fir.rebox codegen is not
impacted and already support those cases.
Add related FIR parsing, error, and codegen tests.
Differential Revision: https://reviews.llvm.org/D121710
This patch removes deprecated parser/printer/verifier fields from
FIROps.td. This is a follow-up of https://reviews.llvm.org/D119776 - it
takes care of operations deriving from `fir_IntegralSwitchTerminatorOp`
and `region_Op`.
No new functionality is added, hence no tests. This patch addresses:
https://github.com/llvm/llvm-project/issues/54314.
Differential Revision: https://reviews.llvm.org/D121406
Some changes were extracted from D121090 (by River Riddle).
co-authored-by: River Riddle <riddleriver@gmail.com>
This patch update the array value copy pass to support fir-array_amend
and fir.array_access.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121300
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Currently, CGOps.h and FIROps.h contain `using namespace mlir;`. Every
file that includes one of these header files (directly and transitively)
will have the MLIR namespace enabled. With name-clashes within
sub-projects (LLVM and MLIR, MLIR and Flang), this is not desired. Also,
it is not possible to "un-use" a namespace once it is "used". Instead,
we should try to limit `using namespace` to implementation files (i.e.
*.cpp).
This patch removes `using namespace mlir;` from header files and adjusts
other files accordingly. In header and TableGen files, extra namespace
qualifier is added when referring to symbols defined in MLIR. Similar
approach is adopted in source files that didn't require many changes. In
files that would require a lot of changes, `using namespace mlir;` is
added instead.
Differential Revision: https://reviews.llvm.org/D120897
This patch enables the lowering of the `sum` intrinsic. It adds
also infrastructure to deal with optional arguments in intrinsics and
implied loops.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121221
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
This patches adds the code to handle host association for
inner subroutines and functions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121134
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This change updates the mapping of derived types and type descriptor
object names to support kind parametrized derived types (PDT).
It moves the custom name mapping to the internal name utility.
To improve robustness and error reporting, type descriptors are also now
required to be generated in all compilation unit that manipulates
derived types. The previous codegen relied on the fact that descriptors
not defined in the current FIR module were available externally. Errors
with missing type descriptors were only caught at link time.
This patch makes derived type definition mandatory, except if the
derived types are expected to not have derived type descriptors (builtin
types), or if the newly added debug switch `--ignore-missing-type-desc`
is set. In those cases, a null pointer is used as type descriptor
pointer. The debug switch intends to help testing FIR to LLVM passes
without having to bother providing type descriptor data structures that
are normally built by the front-end.
Differential Revision: https://reviews.llvm.org/D120804
This patch enables the lowering of the print, read and write
IO statements.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120743
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
The last remaining operations in the standard dialect all revolve around
FuncOp/function related constructs. This patch simply handles the initial
renaming (which by itself is already huge), but there are a large number
of cleanups unlocked/necessary afterwards:
* Removing a bunch of unnecessary dependencies on Func
* Cleaning up the From/ToStandard conversion passes
* Preparing for the move of FuncOp to the Func dialect
See the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061
Differential Revision: https://reviews.llvm.org/D120624
This patch introduce basic function/subroutine calls.
Because of the state of lowering only simple scalar arguments
can be used in the calls. This will be enhanced in follow up
patches with arrays, allocatable, pointer ans so on.
```
subroutine sub1()
end
subroutine sub2()
call sub1()
end
```
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D120419
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Without results, there is no getType injected and so generating one in prefixed form doesn't result in any failures during C++ compilation.
Differential Revision: https://reviews.llvm.org/D119871
`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119812
These have been replaced by `hasCustomAssemblyFormat` and `hasVerifier`
fields and aren't needed anymore.
Ops deriving from `fir_IntegralSwitchTerminatorOp` and `region_Op` are
not handled in this patch for ease of review.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D119776
Replace the hardcoded attribute name with the constexpr StringRef
defined in the FIROps.td file.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D119422
This patch introduces the FIRInlinerInterface.
This class defines the interface for handling inlining of FIR calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D119340
Co-authored-by: Jean Perier <jperier@nvidia.com>
These have generally been replaced by better ODS functionality, and do not
need to be explicitly provided anymore.
Differential Revision: https://reviews.llvm.org/D119065
The `array_access` provides a reference to a single element from an array
value. This is *not* a view in the immutable array, otherwise it couldn't
be stored to. It can be see as a logical copy of the element and its
position in the array. This reference can be written to and modified without
changing the original array.
The `array_access` operation is used to fetch the memory reference of an
element in an array value.
```fortran
real :: a(n,m)
...
... a ...
... a(r,s+1) ...
```
One can use `fir.array_access` to recover the implied memory reference to
the element `a(i,j)` in an array expression `a` as shown above. It can also
be used to recover the reference element `a(r,s+1)` in the second
expression.
```mlir
%s = fir.shape %n, %m : (index, index) -> !fir.shape<2>
// load the entire array 'a'
%v = fir.array_load %a(%s) : (!fir.ref<!fir.array<?x?xf32>>, !fir.shape<2>) -> !fir.array<?x?xf32>
// fetch the value of one of the array value's elements
%1 = fir.array_access %v, %i, %j : (!fir.array<?x?xf32>, index, index) -> !fir.ref<f32>
```
More information about `array_access` and other array operations can be
found in flang/docs/FIRArrayOperations.md.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D112445
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch allows:
- fir.box type to be a member of tuple<> or fir.type<> types,
- tuple<> type to be a member of tuple<> type.
When a fir.box types are nested in tuple<> or fir.type<>, it is translated
to the struct type of a Fortran runtime descriptor, and not a
pointer to a descriptor. This is because the fir.box is owned by the tuple
or fir.type.
FIR type translation was also flattening nested tuple while lowering to LLVM
dialect types. There does not seem to be a deep reason for doing that
and doing it causes issues in fir.coordinate_of generated on such tuple
(a fir.coordinate_of getting tuple<B, C> in tuple<A, tuple<B, C>>
ended-up lowered to an LLVM GEP getting B).
Differential Revision: https://reviews.llvm.org/D118701
OwningRewritePatternList has been deprecated for ~10 months now, we can remove
the leftover using directives at this point.
Differential Revision: https://reviews.llvm.org/D118287
getLoweredName() is not a well suited name change it to
translateNameToFrontendMangledName()
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D118140
This patch just move the files from the Transforms directory to
the Dialect directory.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D117661
BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against the core tenant of MLIR where location
information is a requirement, so this commit updates the API to require locations.
Fixes#53279
Differential Revision: https://reviews.llvm.org/D117633
The leading space that is always printed at the beginning of regions is not consistent with other parts of the printing API. Moreover, this leading space can lead to undesirable assembly formats:
```
attr-dict-with-keyword $region
```
Prints as:
```
// Two spaces between `}` and `{`
attributes {foo} { ... }
```
Moreover, the leading space results in the odd generic op format:
```
"test.op"() ( {...}) : () -> ()
```
Reviewed By: rriddle, mehdi_amini
Differential Revision: https://reviews.llvm.org/D117411
Change dialect (and remove now redundant accessors) to generate both
form of accessors of being generated. Tried to keep this change
reasonably minimal (this also includes keeping note about not generating
getType accessor to avoid shadowing).
Differential Revision: https://reviews.llvm.org/D115420
This patch upstream the array value copy pass.
Transform the set of array value primitives to a memory-based array
representation.
The Ops `array_load`, `array_store`, `array_fetch`, and `array_update` are
used to manage abstract aggregate array values. A simple analysis is done
to determine if there are potential dependences between these operations.
If not, these array operations can be lowered to work directly on the memory
representation. If there is a potential conflict, a temporary is created
along with appropriate copy-in/copy-out operations. Here, a more refined
analysis might be deployed, such as using the affine framework.
This pass is required before code gen to the LLVM IR dialect.
This patch is part of the upstreaming effort from fir-dev branch. The
pass is bringing quite a lot of file with it.
Reviewed By: kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D111337
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Also replace ArrayAttr with IndexElementsAttr to model subscript dimensions.
An array of attribute is a sparse inefficient storage, with an API that
requires to unpack/repack integers at every call site.
Instead we can store dense array of integer as IndexElementsAttr.
Reviewed By: clementval, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D112899
Printing and parsing of constc didn't agree with each other. This patch
treats the parsing of constc as the final word and fixes the printing
accordingly.
More concretely, this patch prints the RealAttrs that make up the
ConstcOp directly instead of casting to mlir::FloatAttr (which blows
up). It also fixes parseFirRealAttr to invoke APFloat's method for
getting the size of a floating point type instead of computing it as
8 * kind (which blows up for BFloat, with kind == 3 and size == 16).
Kudos to Kiran Chandramohan <kiran.chandramohan@arm.com> for noticing
that we were missing tests for constc in fir-ops.fir.
Differential Revision: https://reviews.llvm.org/D114081
Convert a `fir.embox` operation to LLVM IR dialect.
A `fir.embox` is converted to a sequence of operation that
create, allocate if needed, and populate a descriptor.
Current limitiation: alignment is set by default but should be retrieved in the specific target.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D113756
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
NamedAttribute is currently represented as an std::pair, but this
creates an extremely clunky .first/.second API. This commit
converts it to a class, with better accessors (getName/getValue)
and also opens the door for more convenient API in the future.
Differential Revision: https://reviews.llvm.org/D113956
Add a fir.llvm_ptr type to allow any level of indirections
Currently, fir pointer types (fir.ref, fir.ptr, and fir.heap) carry
a special Fortran semantics, and cannot be freely combined/nested.
When implementing some features, lowering sometimes needs more liberty
regarding the number of indirection levels. Add a fir.llvm_ptr that has
no constraints.
Allow its usage in fir.coordinate_op, fir.load, and fir.store.
Convert the FIR LLVMPointer to an LLVMPointer in the LLVM dialect.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D113755
Co-authored-by: Jean Perier <jperier@nvidia.com>
The `fir.select_case` operation is converted to a if-then-else ladder.
Conversion of `fir.select_case` operation with character is not
implemented yet.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113484
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Convert !fir.alloca into !llvm.alloca.
This also contains a fix for verifyInType in FIROps.cpp, to make sure we
can handle a !fir.ptr<!fir.array<?xN>>.
Differential Revision: https://reviews.llvm.org/D113563
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This decouples the printing/parsing from the "context" in which the parsing occurs.
This will allow to invoke these methods directly using an OpAsmParser/OpAsmPrinter.
Differential Revision: https://reviews.llvm.org/D113637
The `fir.select` and `fir.select_rank` are lowered to llvm.switch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D113089
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Sequence type had no restriction on the insert_on_range operation.
This patch adds a restriction for the type to have constant shape
and size.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D113092
This builder exposed a somehow "unsafe" API: it pretends we can
construct an InsertOnRangeOp from a range of SSA values, even though
this will crash if these aren't the result of `arith.constant` since
the operation actually needs attribute values (a build method can't
fail gracefully).
That means that the caller must check for the producer, at which
point they can just assemble the attribute array directly and call
the existing builder.
The existing call-sites were even in a worse state here: they would
actually create a constant operation that wouldn't be used and only
serve to carry the attribute through the builder API.
Differential Revision: https://reviews.llvm.org/D112946
Substring information on slice operation has been added in D112441.
The operations fir.array_load, fir.array_coor and fir.array_merge_store can take
a slice but not with a substring. This patch add this check in their verifier.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D112568
Nimish Mishra