Commit Graph

15 Commits

Author SHA1 Message Date
Valentin Clement 9d99b482cd
[flang] Lower polymorphic entities types in dummy argument and function result
This patch updates lowering to produce the correct fir.class types for
various polymorphic and unlimited polymoprhic entities cases. This is only the
lowering. Some TODOs have been added to the CodeGen part to avoid errors since
this part still need to be updated as well.
The fir.class<*> representation for unlimited polymorphic entities mentioned in
the document has been updated to fir.class<none> to avoid useless work in pretty
parse/printer.

This patch is part of the implementation of the poltymorphic
entities.
https://github.com/llvm/llvm-project/blob/main/flang/docs/PolymorphicEntities.md

Depends on D134957

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D134959
2022-10-04 09:43:59 +02:00
Slava Zakharin 73026a4fbf [flang] Changed lowering for allocatable assignment to make array-value-copy correct.
Array-value-copy fails to generate a temporary array for case like this:
subroutine bug(b)
  real, allocatable :: b(:)
  b = b(2:1:-1)
end subroutine

Since LHS may need to be reallocated, lowering produces the following FIR:
%rhs_load = fir.array_load %b %slice

%lhs_mem = fir.if %b_is_allocated_with_right_shape {
   fir.result %b
} else {
   %new_storage = fir.allocmem %rhs_shape
   fir.result %new_storage
}

%lhs = fir.array_load %lhs_mem
%loop = fir.do_loop {
 ....
}
fir.array_merge_store %lhs, %loop to %lhs_mem
// deallocate old storage if reallocation occured,
// and update b descriptor if needed.

Since %b in array_load and %lhs_mem in array_merge_store are not the same SSA
values, array-value-copy does not detect the conflict and does not produce
a temporary array. This causes incorrect result in runtime.

The suggested change in lowering is to generate this:
%rhs_load = fir.array_load %b %slice
%lhs_mem = fir.if %b_is_allocated_with_right_shape {
   %lhs = fir.array_load %b
   %loop = fir.do_loop {
      ....
   }
   fir.array_merge_store %lhs, %loop to %b
   fir.result %b
} else {
   %new_storage = fir.allocmem %rhs_shape
   %lhs = fir.array_load %new_storage
   %loop = fir.do_loop {
      ....
   }
   fir.array_merge_store %lhs, %loop to %new_storage
   fir.result %new_storage
}
// deallocate old storage if reallocation occured,
// and update b descriptor if needed.

Note that there are actually 3 branches in FIR, so the assignment loops
are currently produced in three copies, which is a code-size issue.
It is possible to generate just two branches with two copies of the loops,
but it is not addressed in this change-set.

Differential Revision: https://reviews.llvm.org/D129314
2022-07-08 09:41:34 -07:00
Valentin Clement 331145e6e9
[flang][NFC] Unify todo messages
This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier

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

Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
2022-06-20 15:44:20 +02:00
Jean Perier c8a9afe7c8
[flang] Handle reversed bounds and negative length in inlined allocation
ALLOCATE statement allows reversed bounds (see Fortran 2018 9.7.1.2
point 1) in which case the extents are zero.

The same applies for the character length provided in the type spec that
can be negative. In which case the new length is zero.

Use genMaxWithZero to deal with these cases.

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

Reviewed By: jeanPerier, PeteSteinfeld

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

Co-authored-by: Jean Perier <jperier@nvidia.com>
2022-06-13 17:35:03 +02:00
vdonaldson 70ade047a4
[flang] system_clock intrinsic calls with dynamically optional arguments
system_clock intrinsic calls with dynamically optional arguments

Modify intrinsic system_clock calls to allow for an argument that is optional
or a disassociated pointer or an unallocated allocatable.  A call with such an
argument is the same as a call that does not specify that argument.

Rename (genIsNotNull -> genIsNotNullAddr) and (genIsNull -> genIsNullAddr)
and add a use of genIsNotNullAddr.

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

Reviewed By: PeteSteinfeld

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

Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
2022-06-13 17:33:28 +02:00
Valentin Clement 5b66cc1000
[flang][NFC] Move Todo.h from Lower to Optimizer
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
2022-06-10 08:51:05 +02:00
Eric Schweitz 1bffc75383 Upstream support for POINTER assignment in FORALL.
Reviewed By: vdonaldson, PeteSteinfeld

Differential Revision: https://reviews.llvm.org/D125140
2022-05-06 19:52:47 -07:00
Valentin Clement fe252f8ed6
[flang] Lower boxed procedure
In FIR, we want to wrap function pointers in a special box known as a
boxproc value. Fortran has a limited form of dynamic scoping
[https://tinyurl.com/2p8v2hw7] between "host procedures" and "internal
procedures". There are a number of implementations possible.

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

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

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

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

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

Reviewed By: jeanPerier, PeteSteinfeld

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

Co-authored-by: mleair <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>
2022-03-22 15:41:11 +01:00
Valentin Clement 94a1106357
[flang] Lower min|max intrinsics
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>
2022-03-15 22:24:10 +01:00
Andrzej Warzynski 092601d4ba [flang] Remove 'using namespace mlir;` from header files
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
2022-03-09 10:19:51 +00:00
Valentin Clement 96d9df4157
[flang] Add test for allocatable on the callee side
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>
2022-03-01 22:58:34 +01:00
Valentin Clement 2a59ead118
[flang] Lower allocatable assignment for scalar
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>
2022-02-24 18:13:18 +01:00
Shraiysh Vaishay 149ad3d554 [flang][mlir][NFC] Replace uses of raw accessors with prefixed accessors
`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.

Reviewed By: clementval

Differential Revision: https://reviews.llvm.org/D119812
2022-02-15 21:07:46 +05:30
River Riddle dec8af701f [mlir] Move SelectOp from Standard to Arithmetic
This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

Differential Revision: https://reviews.llvm.org/D118648
2022-02-02 14:45:12 -08:00
Valentin Clement a2e7af7516
[fir] Add utility function to FIRBuilder and MutableBox
This patch is extracted from D111337 to make is smaller.
It introduce utility functions to the FIRBuilder and add the MutableBox
files.

- genShape
- readCharLen
- getExtents

Reviewed By: kiranchandramohan

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

Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
2021-10-22 10:00:34 +02:00