Remove a backwards dependence from Optimizer -> Lower by moving Todo.h
to the optimizer and out of lowering.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D127292
As Fortran 2018 15.5.2.9 point 2, the actual argument and dummy argument
have the same type and type parameters and an external function with
assumed character length may be associated with a dummy argument with
explicit character length. As Fortran 2018 15.5.2.9 point 7, if an
external procedure is used as an actual argument, it can be explicitly
declared to have the EXTERNAL attribute. This supports the external
procedure passed as actual argument with implicit character type, either
explicit character length or assumed character length.
Reviewed By: Jean Perier, klausler
Differential Revision: https://reviews.llvm.org/D124345
Follow up of https://reviews.llvm.org/D121488. Ensure lower bounds
are `1` when the related dimension extent is zero. Note that lower
bounds from descriptors are now guaranteed to fulfill this property
after the runtime/codegen patches.
Also fixes explicit shape array extent lowering when instantiating
variables to deal with negative extent cases (issue found while testing
LBOUND edge case). This notably caused allocation crashes when dealing
with automatic arrays with reversed bounds or negative size
specification expression. The standard specifies that the extent of such
arrays is zero. This change has some ripple effect in the current lit
tests.
Add move two helpers as part of this change:
- Add a helper to tell if a fir::ExtendedValue describes an assumed size
array (last dimension extent is unknown to the compiler, both at compile
time and runtime).
- Move and share getIntIfConstant from Character.cpp so that it can be
used elsewhere (NFC).
Differential Revision: https://reviews.llvm.org/D122467
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>
This patch adds some tests for the lowering of
array constructors.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121945
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>
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
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 adds the lowering of the `inquire` statement.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120822
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D120823
Co-authored-by: Jean Perier <jperier@nvidia.com>
`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119812
This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into the ecosystem. Given that, as part of
splitting up the standard dialect it's best to just remove this behavior, instead of try
to awkwardly fit it somewhere upstream. Downstream users are encouraged to
define their own operations that clearly can define the semantics of this.
This also uncovered several lingering uses of ConstantOp that weren't
updated to use arith::ConstantOp, and worked during conversions because
the constant was removed/converted into something else before
verification.
See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for more discussion.
Differential Revision: https://reviews.llvm.org/D118654
When passing a character procedure as a dummy procedure, the result
length must be passed along the function address. This is to cover
the cases where the dummy procedure is declared with assumed length
inside the scope that will call it (it will need the length to allocate
the result on the caller side).
To be compatible with other Fortran compiler, this length must be
appended after all other argument just like character objects
(fir.boxchar).
A fir.boxchar cannot be used to implement this feature because it
is meant to take an object address, not a function address.
Instead, argument like `tuple<function type, integer type> {fir.char_proc}`
will be recognized as being character dummy procedure in FIR. That way
lowering does not have to do the argument split.
This patch adds tools in Character.h to create this type and tuple
values as well as to recognize them and extract its tuple members.
It also updates the target rewrite pass to split these arguments like
fir.boxchar.
This part is part of fir-dev upstreaming. It was reviwed previously
in: https://github.com/flang-compiler/f18-llvm-project/pull/1393
Differential Revision: https://reviews.llvm.org/D118108
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
This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.
Reviewed By: schweitz, awarzynski
Differential Revision: https://reviews.llvm.org/D112140
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.
Reviewed By: schweitz, awarzynski
Differential Revision: https://reviews.llvm.org/D112140
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.
Reviewed By: schweitz, awarzynski
Differential Revision: https://reviews.llvm.org/D112140
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Valentin Clement