This patch adds support for lowering of the `set_exponent` intrinsic
from Fortran to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121805
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eun Jung Park <ejpark@lanl.gov>
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 adds lowering for the count intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121782
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
This option is added in both `flang-new` (the compiler driver) and
`flang-new -fc1` (the frontend driver). The semantics are consistent
with `clang` and `clang -cc1`.
As Flang does not run any LLVM passes when invoked with `-emit-llvm`
(i.e. `flang-new -S -emit-llvm <file>`), the tests use
`-S`/`-c`/`-emit-obj` instead. These options require an LLVM backend to
be run by the driver to generate the output (this makese `-mllvm`
relevant here).
Differential Revision: https://reviews.llvm.org/D121374
This patch adds lowering for the `adjustl` and `adjustr`
intrinsics.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121780
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for the `transfer` intrinsic.
The calls are lowered to runtime function calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121777
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
This patch adds support for lowering of the `ibset` intrinsic from Fortran
to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Differential Revision: https://reviews.llvm.org/D121717
This patch adds lowering ofr the `system_clock` intrinsic.
The call is lowered to runtime function call.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D121776
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch lowers the `cpu_time` and the `date_and_time` instrinsics to
FIR and runtime calls.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D121704
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121705
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Thsi patch add the infrastructure to lower the random related
intrinsics:
- `random_init`
- `random_number`
- `random_seed`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121704
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds lowering for the following intrinsics:
- `max`
- `maxloc`
- `maxval`
- `minloc`
- `minval`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121701
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
This patch adds lowering for the following character related intrinsics:
- `len`
- `len_trim`
- `lge`, `lgt`, `lle` and `llt`
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121703
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds lowering for the `allocated`
intrinsic.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121702
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds the lowering infrastructure for the lowering of
alternat returns.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D121698
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121699
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch add the lowering for the entry statement.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D121697
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121698
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch lowers more cases of pointer assignments and
disassociations.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121697
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds support for lowering of the `ibits` intrinsic from Fortran
to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121693
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch adds support for lowering of the `dim` intrinsic from Fortran
to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121689
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch adds support for lowering the `dot_product` intrinsic from
Fortran to the FIR dialect of MLIR.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Differential Revision: https://reviews.llvm.org/D121684
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Co-authored-by: Mark Leair <leairmark@gmail.com>
This patch lowers the `any` intrinsic function to FIR.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121609
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
LBOUND must return 1 for an empty dimension, no matter what
explicit expression might appear in a declaration or arrive in
a descriptor.
Differential Revision: https://reviews.llvm.org/D121488
around the feature in MLIR's canonicalizer, which considers the semantics
of constants differently based on how they are packaged and not their
values and use. Add test.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D121625
This patch lowers common block variable to FIR.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121610
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Lower the `all` intrinsic procedure.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121607
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds more lowering of operations sub-expression inside elemental call arguments.
It tests array contexts where an address is needed for each element (for
the argument), but part of the array sub-expression must be lowered by value
(for the operation)
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121606
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.
Differential Revision: https://reviews.llvm.org/D119918
This patch adds couple of tests for allocatable
globals and missing lowering for them
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121473
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds tests and missing lowering
code to lower elemental function/subroutine calls
in array expression
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121474
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
evaluate::IsPointerObject used to return true for pointer suboject like
`pointer(10)` while these object are not pointers. This prevented some
checks like 15.5.2.7 to be correctly enforced (e.g., it was possible to
pass `pointer(10)` to a non intent(in) dummy pointer).
After updating IsPointerObject behavior and adding a test for 15.5.2.7 in
call07.f90, a test in call03.f90 for 15.5.2.4(14) was failing.
It appeared the related semantics check was relying on IsPointerObject
to return true for `pointer(10)`. Adapt the code to detect pointer element
in another way.
While looking at the code, I also noticed that semantics was
rejecting `character(1)` pointer/assumed shape suboject when these are
allowed (the standard has a special case for character(1) in
15.5.2.4(14), and I verified that other compilers that enforce 15.5.2.4(14)
do accept this).
Differential Revision: https://reviews.llvm.org/D121377
Push the ModuleLikeUnit evalutionList when entering module unit. Pop it
when exiting module unit if there is no module procedure. Otherwise, pop
it when entering the first module procedure.
Reviewed By: V Donaldson
Differential Revision: https://reviews.llvm.org/D120460
OpenMP/OpenACC declarative directives can also be used in module unit.
Add support for dump them in module.
Reviewed By: kiranchandramohan, V Donaldson
Differential Revision: https://reviews.llvm.org/D120459
This patch lowers pointer component part of derived types to
FIR.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D121383
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121384
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch lowers general forall statements. The forall
are lowered to nested loops.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D121385
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121386
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch lowers where statement to FIR.
The where statement is lowered to a conbination of
loops and if conditions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121385
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch lowers basic derived type to FIR.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121383
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds more lowering and tests for character array assignment/copy.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D121300
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121301
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.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>
Add `-fopenacc` flag to the `bbc` tool.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D121117
Add `-fopenmp` flag to the `bbc` tool.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz, awarzynski
Differential Revision: https://reviews.llvm.org/D121118
This patch adds support for:
* `-S` in Flang's compiler and frontend drivers,
and implements:
* `-emit-obj` in Flang's frontend driver and `-c` in Flang's compiler
driver (this is consistent with Clang).
(these options were already available before, but only as placeholders).
The semantics of these options in Clang and Flang are identical.
The `EmitObjAction` frontend action is renamed as `BackendAction`. This
new name more accurately reflects the fact that this action will
primarily run the code-gen/backend pipeline in LLVM. It also makes more
sense as an action implementing both `-emit-obj` and `-S` (originally,
it was just `-emit-obj`).
`tripleName` from FirContext.cpp is deleted and, when a target triple is
required, `mlir::LLVM::LLVMDialect::getTargetTripleAttrName()` is used
instead. In practice, this means that `fir.triple` is replaced with
`llvm.target_triple`. The former was effectively ignored. The latter is
used when lowering from the LLVM dialect in MLIR to LLVM IR (i.e. it's
embedded in the generated LLVM IR module). The driver can then re-use
it when configuring the backend. With this change, the LLVM IR files
generated by e.g. `tco` will from now on contain the correct target
triple.
The code-gen.f90 test is replaced with code-gen-x86.f90 and
code-gen-aarch64.f90. With 2 seperate files we can verify that
`--target` is correctly taken into account. LIT configuration is updated
to enable e.g.:
```
! REQUIRES: aarch64-registered-target
```
Differential Revision: https://reviews.llvm.org/D120568
The front-end and the runtime are currently using the unix logical
representation, but lowering was not. These inconsistencies could
caused issues.
The only place that defines what the logical representation is in
lowering is the translation from FIR to LLVM (FIR is agnostic to the
actual representation). More precisely, the LLVM implementation of
`fir.convert` between `i1` and `fir.logcial` is what defines the
representation:
- `fir.convert` from `i1` to `fir.logical` defines the `.true.` and `.false.`
canonical representations
- `fir.convert` from `fir.logical` to `i1` decides what the test for
truth is.
Unix representation is:
- .true. canonical integer representation is 1
- .false. canonical integer representation is 0
- the test for truth is "integer representation != 0"
For the record, the previous representation that was used was in
codegen was:
- .true. canonical integer representation is -1 (all bits 1)
- .false. canonical integer representation is 0
- the test for truth is "integer representation lowest bit == 1"
Differential Revision: https://reviews.llvm.org/D121200
Using recently established message severity codes, upgrade
non-fatal messages to usage and portability warnings as
appropriate.
Differential Revision: https://reviews.llvm.org/D121246
This patch lowers the `associate` construct.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121239
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch adds support for dumping the pre-FIR tree in `flang-new
-fc1`, i.e. Flang's frontend driver. This flag is functionally identical
to `-pft-test` in `bbc` and semantically similar to
`-fdebug-dump-parse-tree` from `flang-new -fc1`.
Differential Revision: https://reviews.llvm.org/D121198
This patch lowers the computed and assigned goto statements.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D121219
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
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>
When a module uses a derived type that is shadowed by a generic
interface, the module file was missing a USE statement for the
name. Detect and handle this situation.
Differential Revision: https://reviews.llvm.org/D121160
When a structure constructor does not initialize an allocatable component,
ensure that the typed expression representation contains an explicit
NULL() for the component. Expression semantics already copies default
initialized expressions for nonallocatable components into structure
constructors. This change is expected to simplify lowering.
Differential Revision: https://reviews.llvm.org/D121162
This patch add the lowering for the allocate
and the deallocate statements.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D121146
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 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>
The index incrementation code used for FINDLOC, MAXLOC, and MINLOC folding
would crash if the array had a zero extent on the dimension selected with
a DIM= argument since the subscript passed to IncrementSubscripts would
have a value less than the lower bound. Fix, and add tests.
Differential Revision: https://reviews.llvm.org/D121125
This patches modifies PDT runtime type info generation so that it is
easier to handle derived type descriptor in lowering. It changes three
aspects:
1. The symbol name suffix of runtime type info for PDT instantiation is
changed from a serial number unrelated to the types to an encoding of
the instantiated KIND parameters.
2. New runtime type info is not created for each instantiation of PDT without
KIND parameters (only length parameters). Instead, the runtime type
info of the type definition is always used. It is updated to contain
the component descriptions.
3. Runtime type info of PDT instantiation is now always generated in the
scope where the type is defined. If several PDT type instantiation
are made in different scope with the same kind parameters, they will
use the same runtime type info.
Rational of the change:
In lowering, derived type descriptors are not mapped when instantiating derived
type objects. They are mapped later when symbol knowledge is not available anymore.
This mapping is based on the FIR representation of derived types. For
PDT, the FIR type information does not allow deducing the instantiation
scope, it only allows retrieving the type name, the type _definition_
scope, and the kind parameter values. Therefore, in order to be able to
retrieve the derived type descriptor from a FIR type, the derived type
descriptor must be generated in the definition scope and must reflect
the kind parameters. This justifies the need for changes 1. and 3.
above (suffix and scope change). Changes 2. comes from the fact that
all runtime type info of type without kind parameters can be generated
from the type definition, and that because of the suffix change, the
symbol name for type definition and type instantiation are the same.
Although this change is first motivated by how lowering handles derived
types, I believe it is also an improvement from a functional point of
view since this change will allow reducing the number of generated
runtime type info for PDTs, since redundant information (different
instantiations with same kind parameters) will only be generated once.
Differential Revision: https://reviews.llvm.org/D120801
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
Add new IsCompatibleWith() member functions to many classes in evaluate::characteristics
that apply more nuanced compatibility checking for function results, dummy
arguments, and procedure interfaces than the previous tests for complete
equivalence. Use IsCompatibleWith() in semantics for call checking.
Differential Revision: https://reviews.llvm.org/D120844
The symbol table, name resolution, and semantic checks for module
subprograms -- esp. for MODULE FUNCTION and MODULE SUBROUTINE, but
also MODULE PROCEDURE -- essentially assumed that the subprogram
would be defined in a submodule of the (sub)module containing its
interface. However, it is conforming to instead declare a module
subprogram in the *same* (sub)module as its interface, and we need
to handle that case.
Since this case involves two symbols in the same scope with the same
name, the symbol table details for subprograms have been extended
with a pointer to the original module interface, rather than relying
on searching in scopes.
Differential Revision: https://reviews.llvm.org/D120839
Name resolution was properly probing the table of unrestricted
specific intrinsics to find "abs", but failing to capture the
result type and save it in the created symbol table entry.
Differential Revision: https://reviews.llvm.org/D120749
This patch enables the lowering of various allocatable assignements
for character type and numeric types.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120819
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120820
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch enables the lowering of basic modules and functions/subroutines
in modules.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D120819
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
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>
This patches adds lowering for couple of basic io statements such as `flush`,
`endfile`, `backspace` and `rewind`
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120821
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D120822
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds the lowering of open and close statements
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D120821
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds test for allocatable on the caller side.
Lowering for missing features is added as well.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120746
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120748
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds couple of tests for allocatable
on the callee side. Lowering for some missing underlying features
is added as well.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120744
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120746
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 patch enables dynamic array lowering
and use the funcationality inside some IO tests.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120743
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120744
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 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>
An assumed-type actual argument that corresponds to an assumed-rank dummy
argument shall be assumed-shape or assumed-rank.
Differential Revision: https://reviews.llvm.org/D120750
Derived types with allocatable and pointer components cannot
be used in I/O data transfer statements unless they have defined
I/O procedures available (as type-bound or regular generics).
These cases are caught as errors by the I/O runtime library,
but it would be better if they were flagged during compilation.
(Address comment in review: don't use explicit name string lengths.)
Differential Revision: https://reviews.llvm.org/D120675
Just adds some lowering test for complex operations. These were not
added when the lowering landed.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D120672
Lower the power operation for real, integer
and complex.
The power operation is lowered to library calls.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120403
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D120556
This handles the lowering of the logical comparison
to `arith.cmpi` operation. The logical operations `.OR.`, `.AND.`
and `.NOT.` are lowered to `arith.ori`, `arith.andi` and `arith.xori`
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120559
Reviewed By: schweitz, rovka
Differential Revision: https://reviews.llvm.org/D120560
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch handles the lowering of real
comparison operations. The real comparison operations
are lowered to `arith.cmpf` operation.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120561
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch handles the lowering of comprison
operator between integers.
The comparison is lowered to a `arith.cmpi` operation.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz, rovka
Differential Revision: https://reviews.llvm.org/D120559
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch brings in code which can lower a Fortran intrinsic to
a runtime call or an llvm intrinsic. For math intrinsics the
runtime call is to the `math` or `pgmath` library. Non-math
intrinsics are covered by the Flang runtime. A distance computation
mechanism is introduced to find the runtime function that closely
matches the types of the intrinsic call.
In this patch, the `abs` intrinsic is lowered in the following way,
-> Integer version is lowered as a group of MLIR/FIR operations
-> Real version is lowered to llvm intrinsics
-> Complex version is lowered to the `math_hypot` runtime function
This patch is part of upstreaming from the fir-dev branch of https://github.com/flang-compiler/f18-llvm-project
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D120403
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: zacharyselk <zrselk@gmail.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Handles function with character return.
Character scalar results are passed as arguments in lowering so
that an assumed length character function callee can access the result
length.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120558
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 patch adds support for:
* `--target` in the compiler driver (`flang-new`)
* `--triple` in the frontend driver (`flang-new -fc1`)
The semantics of these flags are inherited from `clangDriver`, i.e.
consistent with `clang --target` and `clang -cc1 --triple`,
respectively.
A new structure is defined, `TargetOptions`, that will hold various
Frontend options related to the target. Currently, this is mostly a
placeholder that contains the target triple. In the future, it will be
used for storing e.g. the CPU to tune for or the target features to
enable.
Additionally, the following target/triple related options are enabled
[*]: `-print-effective-triple`, `-print-target-triple`. Definitions in
Options.td are updated accordingly and, to facilated testing,
`-emit-llvm` is added to the list of options available in `flang-new`
(previously it was only enabled in `flang-new -fc1`).
[*] These options were actually available before (like all other options
defined in `clangDriver`), but not included in `flang-new --help`.
Before this change, `flang-new` would just use `native` for defining the
target, so these options were of little value.
Differential Revision: https://reviews.llvm.org/D120246
This patch handles lowering of simple array assignment.
```
a(:) = 10
```
or
```
a(1) = 1
```
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120501
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Test a range of acceptable forms of SYNC TEAM statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC TEAM call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D120099
Test a range of acceptable forms of SYNC MEMORY statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC MEMORY call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D120097
Add lowering for simple assignement on allocatable
scalars.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120483
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D120488
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch handles allocatable dummy argument lowering
in function and subroutines.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D120483
Co-authored-by: Jean Perier <jperier@nvidia.com>
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>
Add ability to lower complex constant.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D120402
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch handles lowering of real constant.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D120354
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch update the PFTBuilder to be able to lower
the construct present in semantics.
This is a building block for other lowering patches that will be posted soon.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld, schweitz
Differential Revision: https://reviews.llvm.org/D120336
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
This patch brings in some initial changes for lowering Fortran
intrinsics. Intrinsics are generally lowered to a mix of FIR and
MLIR operations, runtime calls or LLVM intrinsics. This patch
particularly brings in the lowering of the Fortran `andi` intrinsic
to `arith.andi` in MLIR.
The significant changes are in ConvertExpr.cpp and IntrinsicCall.cpp.
Intrinsic functions occur as part of expressions. Lowering deals with this
in ConvertExpr.cpp in `genval(const Fortran::evaluate::FunctionRef<A> &funcRef)`.
The code in the above mentioned function kicks of a sequence of calls
that ultimately results in a call to the `genIand ` function in
IntrinsicCall.cpp which creates the MLIR `arith.andi` operation.
A few tests are also included.
Note: Generally intrinsics like `iand` can occur in array (elemental)
context, but since that part is not fully supported in lowering, tests
are only added for the scalar context.
This patch is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119990
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: zacharyselk <zrselk@gmail.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>
Lower simple binary operation (+, -, *, /) for scalars.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D120058
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D120063
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Handle negation on scalar expression.
```
res = -a
```
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D120071
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
This patch hanlde lowering of simple scalar assignment.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D120058
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds support for the `-emit-llvm` option in the frontend
driver (i.e. `flang-new -fc1`). Similarly to Clang, `flang-new -fc1
-emit-llvm file.f` will generate a textual LLVM IR file.
Depends on D118985
Differential Revision: https://reviews.llvm.org/D119012
Test a range of acceptable forms of SYNC IMAGES statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC IMAGES call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D118933
Test a range of acceptable forms of SYNC ALL statements,
including combinations with and without the stat-variable
and errmsg-variable present. Also test that several invalid
forms of SYNC ALL call generate the correct error messages.
Differential Revision: https://reviews.llvm.org/D114181
The fortran standard views blanks in IO formats as white space in
non-string contexts. Other compilers extend this to also view horizontal
tabs as white space. Some compilers additionally add other white space
characters to this group.
Add recognition of horizontal and vertical tabs to runtime format
validation code to match what the runtime code currently does.
This patch adds Win32 to the list of supported triples in
`fir::CodeGenSpecifics`. This change means that we can use the "native"
triple, even when running tests on Windows. Currently this affects only
1 test, but it will change once we start adding more tests for lowering
and code-generation.
Differential Revision: https://reviews.llvm.org/D119332
This patch adds infrsatrcutrue to be able to lower
arguments in functions and subroutines.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D119957
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Calls to C_F_POINTER() without the optional SHAPE= third argument
were failing to be recognized as proper calls to the intrinsic,
but the failure was not generating any error message. This led to
a crash in lowering, which rightfully expects a typed expression
to be associated with the call.
So (1) catch silent failures to convert CALL statements as internal
errors, as is done for expressions and assignment statements; and
(2) clean up C_F_POINTER intrinsic handling to cope with only two
arguments and to emit an error for a FPTR= argument with no type.
Differential Revision: https://reviews.llvm.org/D119847
EQUIVALENCE storage association of objects whose types are not
both default-kind numeric storage sequences, or not both default-kind
character storage sequences, are not standard conformant.
However, most Fortran compilers admit such usage, with warnings
in strict conformance mode. This patch allos EQUIVALENCE of objects
that have sequence types that are either identical, both numeric
sequences (of default kind or not), or both character sequences.
Non-sequence types, and sequences types that are not homogeneously
numeric or character, remain errors.
Differential Revision: https://reviews.llvm.org/D119848
When a pointer assignment with bounds remapping has a function
reference as its right-hand side, don't check for array conformance.
Differential Revision: https://reviews.llvm.org/D119845
This patch adds lowering of ranked array as function return.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D119835
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch enables complex type in lowering.
It is tested on function return types.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D119698
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D119700
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch enables scalar real type in lowering.
It is tested on function return types.
This patch is part of the upstreaming effort from fir-dev branch.
Depends on D119698
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D119699
Co-authored-by: Jean Perier <jperier@nvidia.com>
Semantic analysis was emitting a bogus error message when a structure
constructor contains a monomorphic value for a (limited) polymorphic
component of a derived type. The type compatibility test was too
strict; this patch relaxes it a little to allow values that could
be assigned or passed to a variable or dummy argument with that type.
Also add some quotes to an error message that was sometimes confusing
without them, and remove a repeated space character from another.
Differential Revision: https://reviews.llvm.org/D119744
This patch allows the lowring of simple empty function with a
scalar integer or logical return value.
The code in ConvertType.cpp is cleaned up as well. This file was landed
together with the initial flang push and lowering was still a prototype
at that time. Some more cleaning will come with follow up patches.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D119698
Co-authored-by: Jean Perier <jperier@nvidia.com>
While one cannot of course statically initialize an allocatable component
of an instance of a derived type, its mere presence should not prevent
DATA initialization of the other nonallocatable components. Semantics
was treating the existence of an allocatable component as a case of
"default initialization", which it is, but not one that should run
afoul of C877. Add another Boolean argument to IsInitialized() to allow
for a more nuanced test.
Differential Revision: https://reviews.llvm.org/D119449
Currently, code generation was creating weak symbols for derived type
descriptor global it could not find in the current compilation unit.
The rational is that:
- the derived type descriptors of external module derived types are
generated in the compilation unit that compiled the module so that
the type descriptor address is uniquely associated with the type.
- some types do not have derived type descriptors: the builtin derived
types used to create derived type descriptors. The runtime knows
about them and does not need them to accomplish the feat of
describing themselves. Hence, all unresolved derived type descriptors
in codegen cannot be assumed to be resolved at link time.
However, this caused immense debugging pain when, for some reasons, derived
type descriptor that should be generated were not. This caused random
runtime failures instead of a much cleaner link time failure.
Improve this situation by allowing codegen to detect the builtin derived
types that have no derived type descriptors and requiring the other
unresolved derived type descriptor to be resolved at link time.
Also make derived type descriptor constant data since this was a TODO
and makes the situation even cleaner. This requiring telling lowering
which compiler created symbols can be placed in read only memory. I
considered using PARAMETER, but I have mixed feeling using it since that
would cause the initializer expressions of derived type descriptor to
be invalid from a Fortran point of view since pointer targets cannot be
parameters. I do not want to start misusing Fortran attributes, even if
I think it is quite unlikely semantics would currently complain. I also
do not want to rely on the fact that all object symbols with the
CompilerCreated flags are currently constant data. This could easily
change in the future and cause runtime bugs if lowering rely on this
while the assumption is not loud and clear in semantics.
Instead, add a ReadOnly symbol flag to tell lowering that a compiler
generated symbol can be placed in read only memory.
Differential Revision: https://reviews.llvm.org/D119555
Device clause when it occurs with **target enter data** and **target exit data** must be declared with some non negative value. So some changes were made to evaluate the device clause argument to non negative value and throw the expected error when it takes negative value as argument.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D119141
It is generally an error when a USE-associated name clashes
with a name defined locally, but not in all cases; a generic
interface can be both USE-associated and locally defined.
This works, but not when there is also a local subprogram
with the same name, which is valid when that subprogram is
a specific of the local generic. A bogus error issues at
the point of the USE because name resolution will have already
defined a symbol for the local subprogram.
The solution is to collect the names of local generics when
creating the program tree, and then create their symbols as
well if their names are also local subprograms, prior to any
USE association processing.
Differential Revision: https://reviews.llvm.org/D119566
When a scope's symbol has characteriztics whose specification
expressions depend on other non-constant symbols in the same scope,
f18 rightfully emits an error. However, in the case of usage in
specification expressions involving host association, the program is not
invalid. This can arise, for example, in the case of an internal
function whose result's attributes use host-associated variables.
Differential Revision: https://reviews.llvm.org/D119565
There are several checks in the runtime routine for the RESHAPE
intrinsic. Some checks verify things that should have been checked at
compile time while others represent user errors.
This update changes the checks for user errors into calls to "Crash"
which include information about the failing check. This identifies them
as user errors rather than compiler errors.
I also verified that the checks that remain as internal errors are also
checked by the front end. I added a test to the front end's RESHAPE
test to complete the checks.
Differential Revision: https://reviews.llvm.org/D119596
for sequence of character types.
Upstream type test. Upstream test. Fix tests.
Do not run on windows, as that is not an implemented target.
Differential Revision: https://reviews.llvm.org/D119551
Section 10.2.2.4, paragraph 3 states that a procedure pointer with an explicit
interface must have the same characteristics as its target. Previously, we
interpreted this as disallowing such pointers to point to procedures with
implicit interfaces. But several other compilers allow this.
We make an exception for the case where the explicit interface cannot be
called via an implicit interface.
This change makes us allow this, also
Differential Revision: https://reviews.llvm.org/D119404
The second argument to the ASSOCIATED intrinsic must be a valid pointer
or target. The test for this property only checked the last symbol
in a data-reference, but any symbol in the reference with the
POINTER or TARGET attribute will do.
Differential Revision: https://reviews.llvm.org/D119450
Fortran allows forward references to derived types, including
function results that are typed in a prefix of a FUNCTION statement.
If a type is defined in the body of the function, a reference to
that type from a prefix on the FUNCTION statement must resolve to
the local symbol, even and especially when that type shadows one
from the host scope.
The solution is to defer the processing of that type until the
end of the function's specification part. But the language doesn't
allow for forward references to other names in the prefix, so defer
the processing of the type only when it is not an intrinsic type.
The data structures in name resolution that track this information
for functions needed to become a stack in order to make this work,
since functions can contain interfaces that are functions.
Differential Revision: https://reviews.llvm.org/D119448
This patch adds the lowering for the RETURN statement
without alternate returns in the main program or in subroutine
and functions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D119429
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
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>
arguments even in situations where the arguments are required to compute
the LEN value at runtime.
Add tests.
Differential Revision: https://reviews.llvm.org/D119373
`none` is used in `fir.box` type to specify a polymorphic type.
This patch add the conversion from `!fir.box<none>` to LLVM.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D119325
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds support for lowering the Fortran goto statement from
parse-tree to MLIR. The goto statement in Fortran is a form of
unstructured control flow. The statement transfers control to the
code starting at the label specified in the statement. This can be
faithfully represented in MLIR by a branch instruction.
To assist the lowering of code with unstructured control flow, blocks
are created in advance and associated with the relevant pre-fir tree
evaluations.
This is part of the upstreaming effort from the fir-dev branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Reviewed By: clementval, vdonaldson, schweitz, awarzynski
Differential Revision: https://reviews.llvm.org/D118983
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
ISO_Fortran_binding.h was updated with missing entries for CFI
types for REAL and COMPLEX kinds 2,3,10,16. This patch updates TypeCode.h
to use these new types.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: jeanPerier
Differential Revision: https://reviews.llvm.org/D119283
This patch adds support for generating MLIR files in Flang's frontend
driver (i.e. `flang-new -fc1`). `-emit-fir` is added as an alias for
`-emit-mlir`. We may want to decide to split the two in the future.
A new parent class for code-gen frontend actions is introduced:
`CodeGenAction`. We will be using this class to encapsulate logic shared
between all code-generation actions, but not required otherwise. For
now, it will:
* run prescanning, parsing and semantic checks,
* lower the input to MLIR.
`EmitObjAction` is updated to inherit from this class. This means that
the behaviour of `flang-new -fc1 -emit-obj` is also updated (previously,
it would just exit immediately). This change required
`flang/test/Driver/syntax-only.f90` to be updated.
For `-emit-fir`, a specialisation of `CodeGenAction` is introduced:
`EmitMLIRAction`. The key logic for this class is implemented in
`EmitMLIRAction::ExecuteAction`.
Differential Revision: https://reviews.llvm.org/D118985
Previously, when calling a procedure implicitly for which a global scope
procedure symbol with the same name existed, semantics resolved the
procedure name in the call to the global symbol without checking that
the symbol interface was compatible with the implicit interface of the
call.
This could cause expression rewrite and lowering to later badly process
the implicit call assuming a different result type or an explicit
interface. This could lead to lowering crash in case the actual argument
were incompatible with the dummies from the explicit interface.
Emit errors in the following problematic cases:
- If the result type from the symbol did not match the one from the
implicit interface.
- If the symbol requires an explicit interface.
This patch still allows calling an F77 like procedure with different
actual argument types than the one it was defined with because it is
correctly supported in lowering and is a feature in some program
(it is a pointer cast). The two cases that won't be accepted have
little chance to make much sense. Results returning ABIs may differ
depending on the return types, and function that requires explicit
interface usually requires descriptors or specific processing that
is incompatible with implicit interfaces.
Note that this patch is not making a deep analysis, and it will only
catch mistakes if a global symbol and an implicit interface are
involved. Cases where the user provided a conflicting explicit
interface would still require a pass after name resolution to study
conflicts more deeply. But these cases will not crash lowering or
trigger expression rewrite to do weird things.
Differential Revision: https://reviews.llvm.org/D119274
llvm.insertvalue and llvm.extractvalue need LLVM primitive type
for the indexing operands. While upstreaming the TargetRewrite pass the change
was made from i32 to index without knowing this restriction. This patch reverts
back the types used for indexing in the two ops created in this pass.
the error you will receive when lowering to LLVM IR with the current code
is the following:
```
'llvm.insertvalue' op operand #1 must be primitive LLVM type, but got 'index'
```
Reviewed By: jeanPerier, schweitz
Differential Revision: https://reviews.llvm.org/D119253
Handle character constant ofr error code in the STOP statement.
Depends on D118992
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D118993
This patch handles the quiet argument in the STOP statement. It adds
ability to lower LOGICAL constant.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D118897
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds the fir.array_amend operation. this op
is used later in upstreaming patches for the F95 compliance.
The `array_amend` operation marks an array value as having been changed via
a reference obtain by an `array_access`. It acts as a logical transaction
log that is used to merge the final result back with an `array_merge_store`
operation.
```mlir
// fetch the value of one of the array value's elements
%1 = fir.array_access %v, %i, %j : (!fir.array<?x?xT>, index, index) -> !fir.ref<T>
// modify the element by storing data using %1 as a reference
%2 = ... %1 ...
// mark the array value
%new_v = fir.array_amend %v, %2 : (!fir.array<?x?xT>, !fir.ref<T>) -> !fir.array<?x?xT>
```
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D112448
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
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 lower the integer constant code in the STOP statement.
The code is lowered to `arith.constant`.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D118787
Test a range of acceptable forms of co_broadcast calls, including
combinations of keyword and non-keyword actual arguments of
intrinsic and derived type. Also test that several invalid forms
of co_sum call generate the correct error messages.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D113084
When a scope uses an explicit IMPORT statement to import a
symbol from the scope's host, it should not emit a bogus error
message later if that symbol is used in a specification construct.
The code that checks for imports being hidden by local declarations
was not allowing for the presence of host association (or USE)
indirection symbols in the local scope. Fix by using GetUltimate()
before checking for the hidden symbol.
Differential Revision: https://reviews.llvm.org/D118747
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
Lower the PAUSE statement to a runtime call.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D118699
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch lowers STOP statement without arguments
and ERROR STOP. STOP statement with arguments lowering will
come in later patches ince it requires some expression lowering
to be added.
STOP statement is lowered to a runtime call.
Also makes sure we are creating a constant in the MLIR arith constant.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D118697
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
For "USE, INTRINSIC", search only for intrinsic modules;
for "USE, NON_INTRINSIC", do not recognize intrinsic modules.
Allow modules of both kinds with the same name to be used in
the same source file (but not in the same scoping unit, a
constraint of the standard that is now enforced).
The symbol table's scope tree now has a single instance of
a scope with a new kind, IntrinsicModules, whose children are
the USE'd intrinsic modules (explicit or not). This separate
"top-level" scope is a child of the single global scope and
it allows both intrinsic and non-intrinsic modules of the same
name to exist in the symbol table. Intrinsic modules' scopes'
symbols now have the INTRINSIC attribute set.
The search path directories need to make a distinction between
regular directories and the one(s) that point(s) to intrinsic
modules. I allow for multiple intrinsic module directories in
the second search path, although only one is needed today.
Differential Revision: https://reviews.llvm.org/D118631
This patch enable lowering from Fortran to FIR for a basic empty
program. It brings all the infrastructure needed for that. As discussed
previously, this is the first patch for lowering and follow up patches
should be smaller.
With this patch we can lower the following code:
```
program basic
end program
```
To a the FIR equivalent:
```
func @_QQmain() {
return
}
```
Follow up patch will add lowering of more complex constructs.
Reviewed By: kiranchandramohan, schweitz, PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D118436
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
tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler.
This patch update tco pipelines and adds the translation to LLVM IR.
A simple test is added to make sure the tool is working with a simple
FIR program.
More tests will be upstream in follow up patch from the fir-dev branch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, awarzynski, schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D117781
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
This change was suggested in one of the comments for
https://reviews.llvm.org/D115333. Basically, the following usage is
valid, but the current wording suggests otherwise:
```
%1 = fir.coordinate_of %a, %k : (!fir.ref<!fir.array<10 x 10 x i32>>, index) -> !fir.ref<!fir.array<10 x i32>>
```
A test is also added to better document this particular case.
Differential revision: https://reviews.llvm.org/D115929
tco is a tool to test the FIR to LLVM IR pipeline of the Flang compiler.
This patch update tco pipelines and adds the translation to LLVM IR.
A simple test is added to make sure the tool is working with a simple
FIR program.
More tests will be upstream in follow up patch from the fir-dev branch.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: schweitz, mehdi_amini
Differential Revision: https://reviews.llvm.org/D117781
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Andrzej Warzynski <andrzej.warzynski@arm.com>
The intrinsic table entry for INDEX mistakenly required
the optional BACK= argument to be scalar, but it's an
elemental intrinsic that can accept a conforming array.
Differential Revision: https://reviews.llvm.org/D117700
Accept any keyword argument names of the form "An" for
values of n >= 3 in calls to the intrinsic functions MAX, MIN,
and their variants, so long as "n" has no leading zero and
all the keywords are distinct. Previously, f18 was needlessly
requiring the names to be contiguous. When synthesizing keywords
to characterize the procedure's interface, don't conflict with
the program's keywords.
Differential Revision: https://reviews.llvm.org/D117701
Consistent with previously documented policy, in which
BOZ literals are accepted in non-standard-conforming circumstances
where they can be converted to an unambiguous known numeric type,
allow BOZ literals to be passed as an actual argument in a reference
to a procedure whose explicit interface has a corresponding dummy
argument with a numeric type to which the BOZ literal may be
converted. Improve error messages associated with BOZ literal
actual arguments, too: don't emit multiple errors.
Differential Revision: https://reviews.llvm.org/D117698
When variable with the SAVE attribute appears in a pure subprogram,
emit a more specialized error message if the SAVE attribute was acquired
from static initialization.
Differential Revision: https://reviews.llvm.org/D117699
UBOUND, SIZE, and SHAPE folding was still creating expressions that are
invalid on the caller side without the call expression context.
A previous patch intended to deal with this situation (https://reviews.llvm.org/D116933)
but it assumed the return expression would be a descriptor inquiry to
the result symbol, which is not the case if the extent expression is
"scope invariant" inside the called subroutine (e.g., referring to
intent(in) dummy arguments). Simply prevent folding from inlining non
constant extent expression on the caller side.
Folding could be later improved by having ad-hoc folding for UBOUND, SIZE, and
SHAPE on function references where it could try replacing the dummy symbols
by the actual expression, but this is left as a possible later improvement.
Differential Revision: https://reviews.llvm.org/D117686
Subclause 7.5.2.4 lists conditions under which two distinct derived
types are to be considered the same type for purposes of argument
association, assignment, and so on. These conditions are implemented
in evaluate::IsTkCompatibleWith(), but assignment semantics doesn't
use it for testing for intrinsic assignment compatibility. Fix that.
Differential Revision: https://reviews.llvm.org/D117621
When a scalar-valued function with no distinct RESULT
is being called recursively in its own executable part,
emit a better message about the error. Clean up the
code that resolves function vs. array ambiguities in
expression semantics.
Update to address review comment
Differential Revision: https://reviews.llvm.org/D117577
Fold references to the intrinsic function SCALE().
(Also work around some MSVC headaches somehow exposed by
this patch: disable a bogus MSVC warning that began to appear
in unrelated source files, and avoid the otherwise-necessary
use of the "template" keyword in a call to a template member
function of a class template.)
Differential Revision: https://reviews.llvm.org/D117150
Character substrings weren't being folded correctly;
add tests and rework the implementation so that substrings
of literals and named constant character scalars & arrays
are properly folded for use in constant expressions.
Differential Revision: https://reviews.llvm.org/D117343
ENTRY statement names in module subprograms were not acceptable for
use as a "module procedure" in a generic interface, but should be.
ENTRY statements need to have symbols with place-holding
SubprogramNameDetails created for them in order to be visible in
generic interfaces. Those symbols are created from the "program
tree" data structure. This patch adds ENTRY statement names to the
program tree data structure and uses them to generate SubprogramNameDetails
symbols.
Differential Revision: https://reviews.llvm.org/D117345
Very old (pre-'77 standard) codes would use arrays initialized
with Hollerith literals, typically in DATA, as modifiable
formats.
Differential Revision: https://reviews.llvm.org/D117344
Derived types with SEQUENCE must have data components of sequence
types; but this rule is relaxed as common an extension in the case of
pointer components, whose targets' types are not really relevant
to the implementation requirements of sequence types.
Differential Revision: https://reviews.llvm.org/D117158
It's not conforming to specify the SAVE attribute more than
once for a variable, but it also doesn't hurt anything and
isn't fatal in other Fortran compilers. Downgrade the
message to a warning for better portability.
Differential Revision: https://reviews.llvm.org/D117153
This is nonconformant usage, but widely accepted as an extension.
Downgrade the error message to a warning.
Differential Revision: https://reviews.llvm.org/D117152
We already accept assignments of INTEGER to LOGICAL (& vice versa)
as an extension, but not initialization. Extend initialization
to cover those cases.
(Also fix misspelling in nearby comment as suggested by code reviewer.)
Decouple an inadvertent dependence cycle by moving two
one-line function definitions into a header file.
Differential Revision: https://reviews.llvm.org/D117159
Implements part of the legacy "DEC structures" feature from
VMS Fortran. STRUCTUREs are processed as if they were derived
types with SEQUENCE. DATA-like object entity initialization
is supported as well (e.g., INTEGER FOO/666/) since it was used
for default component initialization in structures. Anonymous
components (named %FILL) are also supported.
These features, and UNION/MAP, were already being parsed.
An omission in the collection of structure field names in the
case of nested structures with entity declarations was fixed
in the parser.
Structures are supported in modules, but this is mostly for
testing purposes. The names of fields in structures accessed
via USE association cannot appear with dot notation in client
code (at least not yet). DEC structures antedate Fortran 90,
so their actual use in applications should not involve modules.
This patch does not implement UNION/MAP, since that feature
would impose difficulties later in lowering them to MLIR types.
In the meantime, if they appear, semantics will issue a
"not yet implemented" error message.
Differential Revision: https://reviews.llvm.org/D117151
A bogus error message is appearing for structure constructors containing
values that correspond to unlimited polymorphic allocatable components.
A value of any type can actually be used.
Differential Revision: https://reviews.llvm.org/D117154
When preprocessing "# ARG" in function-like macro expansion,
the preprocessor needs to pop the previously-pushed '#' token
from the end of the resulting token sequence after detecting the
argument name. The code to do this was just wrong in a couple of
ways.
Differential Revision: https://reviews.llvm.org/D117148
When converting a fir.alloca of an array to the LLVM dialect, we used to
multiply the allocated size by all the constant factors encoded in the
array type. This is fine when the array type is converted to the element
type for the purposes of the allocation, but if it's converted to an
array type, then we might be allocating too much space. For example, for
`%2 = fir.alloca !fir.array<8x16x32xf32>, %0, %1` we would allocate
%0 * %1 * 8 * 16 * 32 x llvm.array<32 x array<16 * array<8 x f32>>>. We
really only need to allocate %0 * %1 such arrays.
This patch fixes the issue by taking note of the array type that we're
trying to allocate. It tries to match the behaviour of
LLVMTypeConverter::convertPointerLike, which returns a pointer to the
element type only when the array type doesn't have a constant interior.
We consequently only multiply with the constant factors in the array
type if the array type doesn't have a constant interior.
This has the nice side effect that it gets rid of some redundant
multiplications with the constant 1 in some cases.
Differential Revision: https://reviews.llvm.org/D116926
Cover more of the code paths from LLVMTypeConverter::convertPointerLike
and LLVMTypeConverter::convertSequenceType.
Differential Revision: https://reviews.llvm.org/D116927
Currently, something like `print *, size(foo(n,m))` was rewritten
to `print *, size(foo_result_symbol)` when foo result is a non constant
shape array. This cannot be processed by lowering or reprocessed by a
Fortran compiler since the syntax is wrong (`foo_result_symbol` is
unknown on the caller side) and the arguments are lost when they might
be required to compute the result shape.
It is not possible (and probably not desired) to make GetShape fail in
general in such case since returning nullopt seems only expected for
scalars or assumed rank (see GetRank usage in lib/Semantics/check-call.cpp),
and returning a vector with nullopt extent may trigger some checks to
believe they are facing an assumed size (like here in intrinsic argument
checks: 196204c72c/flang/lib/Evaluate/intrinsics.cpp (L1530)).
Hence, I went for a solution that limits the rewrite change to folding
(where the original expression is returned if the shape depends on a non
constant shape from a call).
I added a non default option to GetShapeHelper that prevents the rewrite
of shape inquiry on calls to descriptor inquiries. At first I wanted to
avoid touching GetShapeHelper, but it would require to re-implement all
its logic to determine if the shape comes from a function call or not
(the expression could be `size(1+foo(n,m))`). So added an alternate
entry point to GetShapeHelper seemed the cleanest solution to me.
Differential Revision: https://reviews.llvm.org/D116933
This supports the following checks for THREADPRIVATE Directive:
```
[5.1] 2.21.2 THREADPRIVATE Directive
A threadprivate variable must not appear in any clause except the
copyin, copyprivate, schedule, num_threads, thread_limit, and if clauses.
```
This supports the following checks for DECLARE TARGET Directive:
```
[5.1] 2.14.7 Declare Target Directive
A threadprivate variable cannot appear in the directive.
```
Besides, procedure name and the entity with PARAMETER attribute cannot
be in the threadprivate directive. The main program name and module name
cannot be in the threadprivate directive and declare target directive.
There is no clear description or restriction about the entity with
PARAMETER attribute in OpenMP 5.1 Specification, and a warning is given.
Reviewed By: kiranchandramohan, shraiysh, NimishMishra
Differential Revision: https://reviews.llvm.org/D114941
F18 constraint C1308 is:
For the G edit descriptor, e shall not be specified if w is zero.
For an edit descriptor such as 'G0.2E4', change the error message from:
error: Unexpected 'e' in 'G0' edit descriptor
To:
error: A 'G0' edit descriptor must not have an 'e' value
Uses the recursive type conversion implemented in D113579, D113580.
Tests check for recursive and mutually recursive types.
Note: The downstream implementation for recursive types is a bit old
and is based on a static map. This was removed while upstreaming
(https://reviews.llvm.org/D112961) based on review comments. Since
the recursive type conversion is now available in MLIR we are using
that. If this patch is accepted we can use the same in the downstream
implementation.
Part of upstreaming flang from fir-dev branch of https://github.com/flang-compiler/f18-llvm-project.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D115937
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Test a range of acceptable forms of co_max calls, including
combinations of keyword and non-keyword actual arguments of
numeric types. Also test that several invalid forms of
co_max call generate the correct error messages.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D113083
Test various acceptable forms of co_min calls, including
combinations of keyword and non-keyword actual arguments of
integer, real, and character types. Also test that several
invalid forms of co_min call generate the correct error messages.
Reviewed By: ktras
Differential Revision: https://reviews.llvm.org/D113077
Test a range of acceptable forms of co_reduce calls, including
combinations of keyword and non-keyword actual arguments of
numeric types. Also test that several invalid forms of
co_reduce call generate the correct error messages.
Reviewed By: kiranchandramohan, ktras, ekieri
Differential Revision: https://reviews.llvm.org/D113086
This patch extends the `FIRToLLVMLowering` pass in Flang by extending
the hook to transform `fir.coordinate_of` into a sequence of LLVM MLIR
instructions (i.e. `CoordinateOpConversion::doRewrite`). The following
case is added:
3.1 the input object is inside `!fir.ref` (e.g. `!fir.ref<!fir.array>` or
`!fir.ref<!fir.type>`).
3.2 the input object is inside `!fir.ptr` (e.g. `!fir.ptr<!fir.array>` or
`!fir.ptr<!fir.type>`).
From the point of view of the conversion, 3.1 and 3.2 are currently identical.
This is part of the upstreaming effort from the `fir-dev` branch in [1].
[1] https://github.com/flang-compiler/f18-llvm-project
Originally written by:
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Depends on: D114159
Differential Revision: https://reviews.llvm.org/D115333
With this change, the following invocations will be treated as errors
(multiple actions are specified):
```
$ flang-new -fc1 -E -fsyntax-only file.95
$ flang-new -fc1 -fsyntax-only -fdebug-dump-symbols file.95
```
In the examples above it is not clear whether it is `-fsyntax-only` or
the other action that is run (i.e. `-E` or `-fdebug-dump-symbols`). It
makes sense to disallow such usage. This should also lead to cleaner and
clearer tests (the `RUN` lines using `%flang_fc1` will only allow one
action).
This change means that `flang-new -fc1` and `clang -cc1` will behave
differently when multiple action options are specified. As frontend
drivers are mostly used by compiler developers, this shouldn't affect or
confuse the compiler end-users. Also, `flang-new` and `clang` remain
consistent.
Tests are updated accordingly. More specifically, I've made sure that
every test specifies only one action. I've also taken the opportunity to
simplify "multiple-input-files.f90" a bit.
Differential Revision: https://reviews.llvm.org/D111781
This pass can reclassify memory allocations (fir.alloca, fir.allocmem)
based on heuristics and settings. The intention is to allow better
performance and workarounds for conditions such as environments with
limited stack space.
Currently, implements two conversions from stack to heap allocation.
1. If a stack allocation is an array larger than some threshold value
make it a heap allocation.
2. If a stack allocation is an array with a runtime evaluated size make
it a heap allocation.
Add a lit test for both suboptions.
Reviewed By: PeteSteinfeld, vdonaldson
Differential Revision: https://reviews.llvm.org/D115763
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `!fir.coordinate_of` into a sequence of LLVM MLIR
instructions.
The following cases are currently supported:
1. the input object is a `!fir.complex` (wrapped in e.g. `!fir.ref` or
`!fir.box`)
2. the input object is wrapped in a `!fir.box` (including e.g.
`!fir.array`).
Note that `!fir.complex` inside a `!fir.box` falls under case 1. above
(i.e. it's a special case regardless of the wrapping type).
This is part of the upstreaming effort from the `!fir-dev` branch in [1].
Differential Revision: https://reviews.llvm.org/D114159
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Array constructors with implied DO loops that oversee structure
constructors were being prematurely folded into invalid constants
containing symbolic references to the ac-implied-do indices,
because they are indeed "constant expressions" as that term is
used in the Fortran standard and implemented as IsConstantExpr().
What's actually needed in structure constructor folding is a
test for actual constant values, which is what results from
folding them later with repetition in the context of folding
an ac-implied-do.
Differential Revision: https://reviews.llvm.org/D115470
This patch is part of the upstreaming effort from the fir-dev branch.
Address review comments
- move CHECK blocks to after the mlir code in the test file
- fix style with respect to anonymous namespaces: only include class definitions in the namespace and make functions static and outside the namespace
- fix a few nits
- remove TODO in favor of notifyMatchFailure
- removed unnecessary CHECK line from convert-to-llvm.fir
- rebase on main - add TODO back in
- get successfull test of TODO in AllocMemOp converion of derived type with LEN params
- clearer comments and reduced use of auto
- move defintion of computeDerivedTypeSize to fix build error
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Reviewed By: awarzynski, clementval, kiranchandramohan, schweitz
Differential Revision: https://reviews.llvm.org/D114104
The XRebox Op is formed by the codegen rewrite which makes it easier to
convert the operation to LLVM. The XRebox op includes the information
from the rebox op and the associated slice, shift, and shape ops.
During the conversion process a new descriptor is created for reboxing.
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D114709
This patch adds the conversion pattern for the fircg.ext_array_coor
operation. It applies the address arithmetic on a dynamically shaped, shifted
and/or sliced array.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D113968
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
The definition of the EXPONENT() intrinsic function differs by one
from the real arithmetic folding templates concept of an unbiased
exponent, and also needs special handling for zero. Fix, and add
more tests.
Differential Revision: https://reviews.llvm.org/D115084
Rewrite AddrOfOp if taking the address of a function.
Differential Revision: https://reviews.llvm.org/D114925
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Convert a fircg.ext_embox operation to LLVM IR dialect.
A fircg.ext_embox is converted to a sequence of operation that
create, allocate if needed, and populate a descriptor.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D114148
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
For unimplemented patterns we revert to using TODO hard failures instead of
notifyMatchFailure.
For fir.select_type revert to using mlir::emiterror.
For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm.
Adding negative tests using not and checking for the error message.
TODO exits with an error in a build without assertion but aborts in a
build with assertions. Abort requires using not with the --crash
option. The two different usages of not is handled by using a custom
command %not_todo_cmd which is converted to not or not --crash
depending on the presence or absence of assertions. Using llvm-config
to check the presence of assertions.
Reviewed By: clementval, awarzynski
Differential Revision: https://reviews.llvm.org/D114371
For unimplemented patterns we revert to using TODO hard failures instead of
notifyMatchFailure.
For fir.select_type revert to using mlir::emiterror.
For the fir.embox TODO on a type with len params we cannot add a test since the type cannot be converted to llvm.
Adding negative tests using not and checking for the error message.
TODO exits with an error in a build without assertion but aborts in a
build with assertions. Abort requires using not with the --crash
option. The two different usages of not is handled by using a custom
command %not_todo_cmd which is converted to not or not --crash
depending on the presence or absence of assertions. Using llvm-config
to check the presence of assertions.
Reviewed By: clementval, awarzynski
Differential Revision: https://reviews.llvm.org/D114371
Max(), MIN(), and their specific variants are defined with an unlimited
number of dummy arguments named A1=, A2=, &c. whose names are almost never
used in practice but should be allowed for and properly checked for the
usual errors when they do appear. The intrinsic table's entries otherwise
have fixed numbers of dummy argument definitions, so add some special
case handling in a few spots for MAX/MIN/&c. checking and procedure
characteristics construction.
Differential Revision: https://reviews.llvm.org/D114750
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>