The changes convert hlfir.designate to fir.array_coor/fir.embox
to represent a subscripted element of a polymorphic array.
The type information is conveyed via the fir.embox's source_box.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D152200
This patch fixes an unused variable warning that was caused by the task
depend patch.
Original Commit: 3373c8405c5e144567c2b25c28b54b4ac63b09b6
Original Differential Revision: https://reviews.llvm.org/D146766
This patch adds support for the OpenMP 4.0 depend clause for the task
construct, excluding array sections, to Flang lowering from parse-tree
to MLIR.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D146766
A CHECK() was firing when a call to the PACK intrinsic does not have a
VECTOR= argument and at least one dimension of the shape of the ARRAY=
argument could not be determined. The CHECK was inappropriate, since
this can of course happen, such as when that argument is the result
of the SPREAD() intrinsic with non-constant DIM= or NCOPIES= arguments.
Replace with an if() statement.
Differential Revision: https://reviews.llvm.org/D152212
Unstructured regions presents some issues for OpenMP code generation.
While there are no branches out of the OpenMP region, there can be
branches inside. This required the availability of an artificial
target at the end of an OpenMP region. This was implemented by
insertion an artifical `continue` and marking it as a target for
a branch.
(https://github.com/flang-compiler/f18-llvm-project/pull/1178)
The artificial target is not required for OpenMP loops. Since the
DO loop end can itself be a target of a branch. Moreover, insertion
of the continue between the end of the loop and the end of the
OpenMP loop construct presents problems since the OpenMP MLIR
loop construct models both the loop and the construct. This can
cause the terminator of the OpenMP loop construct to be missed.
This patch solves the issue by skipping the insertion of the
continue.
Note: This issue is only hit if the `end openmp loop` directive
is missed.
This patch fixes the issues in:
-> https://github.com/llvm/llvm-project/issues/58378
-> https://github.com/flang-compiler/f18-llvm-project/issues/1426Fixes#58378
Reviewed By: vdonaldson
Differential Revision: https://reviews.llvm.org/D151700
This patch adds PFT lowering for the OpenMP declare target directive
in Flang to the omp dialects declare target attribute, which currently
applies to function or global operations.
Reviewers: kiranchandramohan, skatrak, jsjodin
Differential Revision: https://reviews.llvm.org/D150329
OpenMP standard (section 3.3 for OpenMP 5.2) requires that _OPENMP macro
contains release date of given OpenMP standard version.
Differential Revision: https://reviews.llvm.org/D151083
Reviewed By: kiranchandramohan
Previously only a constant reference was stored in the FirOpBuilder.
However, a lot of code was merged using
FirOpBuilder builder{rewriter, getKindMapping(mod)};
This is incorrect because the KindMapping returned will go out of scope
as soon as FirOpBuilder's constructor had run. This led to an infinite
loop running some tests using HLFIR (because the stack space containing
the kind mapping was re-used and corrupted).
One solution would have just been to fix the incorrect call sites,
however, as a large number of these had already made it past review, I
decided to instead change FirOpBuilder to store its own copy of the
KindMapping. This is not costly because nearly every time we construct a
KindMapping is exclusively to construct a FirOpBuilder. To make this
common pattern simpler, I added a new constructor to FirOpBuilder which
calls getKindMapping().
Differential Revision: https://reviews.llvm.org/D151881
The old fir.allocmem operation returned a !fir.heap<.> type. The new
fir.alloca operation returns a !fir.ref<.> type. This patch inserts a
fir.convert so that the old type is preserved. This prevents verifier
failures when types returned from fir.if statements don't match the
expected type.
Differential Revision: https://reviews.llvm.org/D151921
The code is used, for example, when passing arguments to IO or intrinsic
calls as value. The allocatable/pointer boxes must be dereferenced,
and trivial values have to be loaded. Character and derived values
have to stay boxed.
I am not sure what to do for the array cases, and I have not seen
any test triggering it, so I leave it as a TODO.
Reviewed By: tblah, clementval
Differential Revision: https://reviews.llvm.org/D151925
Currently symbols are not resolved for declare target
after they've been modified by prior passes. This can
lead to missing or incorrect symbols in subsequent
compiler phases when declare target is used with
more complex types e.g. common block.
This patch should allow these symbols to be
resolved appropriately.
Reviewers: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D151993
Per 15.5.2.5 p2, when both a dummy data object and its associated
actual argument are ALLOCATABLE or POINTER, there are rules requiring
that both be unlimited polymorphic if either is, and that both be
polymorphic if either is. The justifications for the first restriction
is that the called procedure might change the type of an unlimited
polymorphic dummy argument, but as this cannot occur for a dummy
argument with INTENT(IN), we can relax the check to an optional
portability warning. The justification for the second restriction
is that some implementations would have to create a type descriptor
to associate a monomorphic allocatable/pointer actual argument with
a polymorphic dummy argument, and that doesn't apply to f18 since we
use descriptors for them anyways.
Relaxing these needless checks allows more library procedures to
use "class(*), dimension(..), pointer, intent(in)" dummy arguments
in explicit interfaces.
Differential Revision: https://reviews.llvm.org/D151941
The insertion of a space on a line continuation right before
a character literal was confusing TokenSequence::ToLowerCase(),
that was unable to identify the character literal as such,
causing it to be converted to lower case.
Fix this by skipping spaces in the beginning and end of each
token, before testing for token type.
Fixes https://github.com/llvm/llvm-project/issues/62039
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D151885
In review for https://reviews.llvm.org/D146278, @vzakhari asked to
separate -emit-fir and -emit-hlfir. This will allow FIR to be easily
outputted after the HLFIR passes have been run.
The new semantics are as follows:
| Action | -flang-experimental-hlfir? | Result |
| =========== | ========================== | =============================== |
| -emit-hlfir | N | Outputs HLFIR |
| -emit-hlfir | Y | Outputs HLFIR |
| -emit-fir | N | Outputs FIR, using old lowering |
| -emit-fir | Y | Outputs FIR, lowering via HLFIR |
A patch for bbc will follow.
Differential Revision: https://reviews.llvm.org/D151088
Despite me being convinced that the use of divide didn't produce any
divide instructions, it does in fact add more instructions than using
a plain shift operation.
This patch simply changes the divide to a shift right, with an
assert to check that the "divisor" is a power of two.
Reviewed By: kiranchandramohan, tblah
Differential Revision: https://reviews.llvm.org/D151880
This revision implements the Fortran intrinsic procedures COMPILER_VERSION and COMPILER_OPTIONS from the iso_fortran_env module.
To be able to set the COMPILER_OPTIONS string according to the original compiler driver invocation, a string is passed to the frontend driver using the environment variable FLANG_COMPILER_OPTIONS_STRING, for lack of a better mechanism.
Fixes#59233
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D140524
Add support for the * operation in OpenACC lowering. Support is added
for the types currently supported.
Depends on D151564
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D151565
Add initial support to lower reduction clause to its representation in MLIR.
This patch adds support for addition of integer and real scalar types. Other
operators and types will be added with follow up patches.
Reviewed By: razvanlupusoru
Differential Revision: https://reviews.llvm.org/D151564
I tried this patch, first. Some tests failed because of the extra
finalizations for the temporary LHSs: when LHS component is a derived
type with final subprograms, the finalizations might be detected
by counting/printing in the final subprograms and treated as errors
in the tests, because they are not expected.
So I also tried to reuse the StructureConstructor code lowering to FIR
followed by AsExprOp to produce the HLFIR "value". Unfortunately,
this did not resolve the finalization issues, because AsExprOp may
end up being bufferized into AssignOp as well.
So the extra finalizations are inherent problem for AssignOp,
and it has to be resolved separately. Thus, I decided to proceed
with a "cleaner" direct lowering to HLFIR (the initial patch).
I am thinking about adding an extra flag for AssignOp that would
indicate that the LHS is a compiler generated temporary, so we could
use something like AssignTemporary() in HLFIR-to-FIR converter.
Reviewed By: tblah
Differential Revision: https://reviews.llvm.org/D151752
Add representations of CUDA Fortran data and subprogram attributes
to the symbol table and scopes of semantics. Set them in name
resolution, and emit them to module files.
Depends on https://reviews.llvm.org/D150159.
Differential Revision: https://reviews.llvm.org/D150161
Begin upstreaming of CUDA Fortran support in LLVM Flang.
This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps
... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.
Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.
More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.
Differential Revision: https://reviews.llvm.org/D150159
Current implementations of x87 80-bit extended precision floating
point interpret 7FFF8000000000000000 as +Inf, not a Nan. The explicit
MSB in the significand must be set for an infinity.
Differential Revision: https://reviews.llvm.org/D151739
When computing the shape of an expression at compilation time as part of
folding an intrinsic function like SIZE(), don't create an expression that
increases a dependence on the presence of an optional dummy argument.
Differential Revision: https://reviews.llvm.org/D151737
In the future we intend to add support for many PowerPC-specific intrinsics that ideally will exist in a separate new PPCIntrinsicCall file. But first we need to move definitions to the IntrinsicCall header file to increase code cleanliness and readability and to make code reusable for when we add PPCIntrinsicCall.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D151715
In upstream mlir, the dialect conversion infrastructure is used for
lowering from one dialect to another: the passes are of the form
XToYPass. Whereas, transformations within the same dialect tend to use
applyPatternsAndFoldGreedily.
In this case, the full complexity of applyPatternsAndFoldGreedily isn't
needed so we can get away with the simpler applyOpPatternsAndFold.
This change was suggested by @jeanPerier
The old differential revision for this patch was
https://reviews.llvm.org/D150853
Re-applying here fixing the issue which led to the patch being reverted. The
issue was from erasing uses of the allocation operation while still iterating
over those uses (leading to a use-after-free). I have added a regression
test which catches this bug for -fsanitize=address builds, but it is
hard to reliably cause a crash from the use-after-free in normal builds.
Differential Revision: https://reviews.llvm.org/D151728
This patch makes more than 2D arrays work, with a fix for the way that
loop index is calculated. Removing the restriction of number of
dimensions.
This also changes the way that the actual index is calculated, such that
the stride is used rather than the extent of the previous dimension. Some
tests failed without fixing this - this was likely a latent bug in the
2D version too, but found in a test using 3D arrays, so wouldn't
have been found with 2D only. This introduces a division on the index
calculation - however it should be a nice and constant value allowing
a shift to be used to actually divide - or otherwise removed by using
other methods to calculate the result. In analysing code generated with
optimisation at -O3, there are no divides produced.
Some minor refactoring to avoid repeatedly asking for the "rank" of the
array being worked on.
This improves some of the SPEC-2017 ROMS code, in the same way as the
limited 2D array improvements - less overhead spent calculating array
indices in the inner-most loop and better use of vector-instructions.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D151140
Adds a new HLFIR operation for the ALL intrinsic according to the
design set out in flang/docs/HighLevel.md
Differential Revision: https://reviews.llvm.org/D151090
This reverts commit d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6.
Adds the patch by @hans from
https://github.com/llvm/llvm-project/issues/62719
This patch fixes the Windows build.
d763c6e5e2d0a6b34097aa7dabca31e9aff9b0b6 reverted the reviews
D144509 [CMake] Bumps minimum version to 3.20.0.
This partly undoes D137724.
This change has been discussed on discourse
https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-version/66193
Note this does not remove work-arounds for older CMake versions, that
will be done in followup patches.
D150532 [OpenMP] Compile assembly files as ASM, not C
Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.
Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.
Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.
D150688 [cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump
The build uses other mechanism to select the runtime.
Fixes#62719
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D151344
It seems the canonicalization was not correct: it cannot return that
it failed if it did modify the IR.
This was exposed by a new MLIR sanity check added in
https://reviews.llvm.org/D144552.
I am not sure it is legit to return success if the operation being
canonicalized is not modified either. So only remove the loads if
they are the only uses of the forall_index.
Should fix (intermittent?) bot failures like
https://lab.llvm.org/buildbot/#/builders/179/builds/6251
since the new MLIR check was added.
Differential Revision: https://reviews.llvm.org/D151487
This patch is to remove the conversion of the actual argument that
is associated with the dummy argument specified with the IGNORE_TKR
directive.
Commit on behalf of @danielcchen
Differential Revision: https://reviews.llvm.org/D151401
In some scenarios, a SELECT CASE could cause an error while lowering to FIR.
This was caused by a spurious extra branch added after the end statement.
Fixes#62726
Differential Revision: https://reviews.llvm.org/D151118
The copy must made according to the actual type, not the dummy type. In
case the dummy is polymorphic, these types will be different and the
dynamic type of the copy passed in the call should be the one of the
actual.
There is no support for "class(t), value" yet (it is hitting a TODO in
CallInterface that is moot for HLFIR but has not been lifted for lack of
proper testing) so the bug was dormant, but D151271 created a situation
where a copy is needed with polymorphic dummies and exposed the bug.
This led to a compile time assert
"value.isScalar() && fir::isa_trivial(value.getType())" in "hlfir::genAssociateExpr".
Differential Revision: https://reviews.llvm.org/D151413
InlineElementals created a regression when inlining elemental
expressions where the type of the result of the hlfir.apply does not
match the hlfir.yield.
This patch ensures the pass doesn't match in these cases, fixing the
regression.
It isn't clear to me what the /right/ solution is:
- Is it actually valid for the hlfir.apply to have a different type
(even just different array bounds?). Should this be enforced in the
verifier?
- Inserting a convert if these types don't match doesn't work because
fir.convert doesn't know how to convert a hlfir.expr. Should this be
added?
Test case is from @vzakhari
Differential Revision: https://reviews.llvm.org/D151202
Generate temporary storage inside WHERE and FORALL using the temporary
stack runtime. This covers all cases outside of LHS temporary, where the
descriptor stack will have to be used.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D151251
Generate temporary storage inline inside WHERE and FORALL when possible.
A following patch will use the runtime to cover the generic cases.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D151247
Now that operands have moved to the new data operands lowering, this
function is not used anymore.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D151357
