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
Move the Factory.h header file to flang/Optimizer/Builder.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D115801
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
Change dialect (and remove now redundant accessors) to generate both
form of accessors of being generated. Tried to keep this change
reasonably minimal (this also includes keeping note about not generating
getType accessor to avoid shadowing).
Differential Revision: https://reviews.llvm.org/D115420
- Join indirection and rank into a single value `flags`
- Make the struct a plain C struct.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D115464
Some of the function name in the comment didn't match
their actual name in the runtime. This patch fixes that.
Reviewed By: schweitz
Differential Revision: https://reviews.llvm.org/D115076
Prior to the introduction of the FLUSH statement in Fortran 2003,
implementations provided a FLUSH subroutine.
We can't yet put Fortran code into the runtime, so this subroutine
is in C++ with a Fortran-mangled entry point name.
Differential Revision: https://reviews.llvm.org/D115289
This patch introduces a bunch of builder functions
to create function calls to runtime ragged arrays functions.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D114535
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
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 runtime function to allocate and
deallocate ragged arrays.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D114534
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
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
This patch adds the FIR builder to generate the numeric intrinsic
runtime call.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D114900
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
This patch adds the builder to generate derived type runtime API calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D114472
Co-authored-by: Peter Klausler <pklausler@nvidia.com>
Co-authored-by: Jean Perier <jperier@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>
This patch adds the FIR builder to generate the numeric intrinsic
runtime call.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D114477
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Some kinds of Fortran arrays are declared with the same syntax,
and it is impossible to tell from a shape (:, :) or (*) whether
the object is assumed shape, deferred shape, assumed size, implied
shape, or whatever without recourse to more information about the
symbol in question. This patch softens the names of some predicate
functions (IsAssumedShape to CanBeAssumedShape) and makes others
more reflective of the syntax they represent (isAssumed to isStar)
in an attempt to encourage coders to seek and find definitive
predicate functions whose names deliver what they seem to mean.
Address TODO comments in IsSimplyContiguous() by using the
updated IsAssumedShape() predicate.
Differential Revision: https://reviews.llvm.org/D114829
This patch introduces a bunch of builder functions
to create function calls to runtime reduction functions.
This patch is part of the upstreaming effort from fir-dev branch.
This patch failed previously because a macro was missing.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D114460
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
A quick fix last week to the shared library build caused
the predicate IsCoarray(const Symbol &) to be moved from
Semantics to Evaluate. This patch completes that move in
a way that properly combines the existing IsCoarray() tests
for expressions and other object with the test for a symbol.
Differential Revision: https://reviews.llvm.org/D114806
Create a new flang/runtime/support.cpp module to hold miscellaneous
runtime APIs to support lowering, and define an API IsContiguous() to
wrap the member function predicate Descriptor::IsContiguous().
And do a little clean-up of other API headers that don't need to expose
Runtime/descriptor.h.
Differential Revision: https://reviews.llvm.org/D114752
This patch introduces a bunch of builder functions
to create function calls to runtime reduction functions.
This patch is part of the upstreaming effort from fir-dev branch.
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Differential Revision: https://reviews.llvm.org/D114460
Reviewed By: awarzynski
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>
Add pass to perform store/load forwarding and potentially removing dead
stores.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, schweitz, mehdi_amini, awarzynski
Differential Revision: https://reviews.llvm.org/D111288
This patch adds the builder that generate assignment runtime API calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka, awarzynski
Differential Revision: https://reviews.llvm.org/D114475
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds the builder to generate transformational
intrinsic runtime API calls.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: rovka
Differential Revision: https://reviews.llvm.org/D114470
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: mleair <leairmark@gmail.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>
This patch adds the common base shared by builder runtime
unittests. It extracted from D114460 to make it easier to base other patches
on it.
Reviewed By: kiranchandramohan, rovka
Differential Revision: https://reviews.llvm.org/D114557
Also replace ArrayAttr with IndexElementsAttr to model subscript dimensions.
An array of attribute is a sparse inefficient storage, with an API that
requires to unpack/repack integers at every call site.
Instead we can store dense array of integer as IndexElementsAttr.
Reviewed By: clementval, kiranchandramohan
Differential Revision: https://reviews.llvm.org/D112899
The predicate IsCoarray() needs to be in libFortranEvaluate so that
IsSaved() can call it without breaking the shared library build.
Pushed without pre-commit review as I'm moving code around and
the fix to the shared build is confirmed.
This legacy option (available in other Fortran compilers with various
spellings) implies the SAVE attribute for local variables on subprograms
that are not explicitly RECURSIVE. The SAVE attribute essentially implies
static rather than stack storage. This was the default setting in Fortran
until surprisingly recently, so explicit SAVE statements & attributes
could be and often were omitted from older codes. Note that initialized
objects already have an implied SAVE attribute, and objects in COMMON
effectively do too, as data overlays are extinct; and since objects that are
expected to survive from one invocation of a procedure to the next in static
storage should probably be explicit initialized in the first place, so the
use cases for this option are somewhat rare, and all of them could be
handled with explicit SAVE statements or attributes.
This implicit SAVE attribute must not apply to automatic (in the Fortran sense)
local objects, whose sizes cannot be known at compilation time. To get the
semantics of IsSaved() right, the IsAutomatic() predicate was moved into
Evaluate/tools.cpp to allow for dynamic linking of the compiler. The
redundant predicate IsAutomatic() was noticed, removed, and its uses replaced.
GNU Fortran's spelling of the option (-fno-automatic) was added to
the clang-based driver and used for basic sanity testing.
Differential Revision: https://reviews.llvm.org/D114209
Step towards removing the hard coded behavior for this trait and to instead use common interface.
Differential Revision: https://reviews.llvm.org/D114208
Use the factory class in the FIRBuilder.
Add unit tests for the factory class function and the convert function
of the Complex class.
Reviewed By: clementval, rovka
Differential Revision: https://reviews.llvm.org/D114125
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Convert a `fir.embox` operation to LLVM IR dialect.
A `fir.embox` is converted to a sequence of operation that
create, allocate if needed, and populate a descriptor.
Current limitiation: alignment is set by default but should be retrieved in the specific target.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, awarzynski
Differential Revision: https://reviews.llvm.org/D113756
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Fortran defines LEN(X) = 0 after CHARACTER(LEN=-1)::X so
apply MAX(0, ...) to character length expressions.
Differential Revision: https://reviews.llvm.org/D114030
Patch D113697 added default function arguments to template specializations of `ConvertToBinary`.
According to https://en.cppreference.com/w/cpp/language/template_specialization this not allowed:
> Default function arguments cannot be specified in explicit specializations of function templates, member function templates, and member functions of class templates when the class is implicitly instantiated.
It happens to compile with gcc, clang and msvc 14.30 (Visual Studio 2022), but not msvc 14.29 (Visual Studio 2020). Even for the compilers that syntactically accept it, the default argument will never be used (only the default argument of the template declaration). From https://en.cppreference.com/w/cpp/language/function_template
> Note that only non-template and primary template overloads participate in overload resolution.
That is, the explicit function template specialization is not added to the overload candidate set. Only after all the parameter types are known, are the explicit specializations chosen, at which point the default function argument is ignored.
Also see D85657.
Reviewed By: klausler
Differential Revision: https://reviews.llvm.org/D114032
Add a fir.llvm_ptr type to allow any level of indirections
Currently, fir pointer types (fir.ref, fir.ptr, and fir.heap) carry
a special Fortran semantics, and cannot be freely combined/nested.
When implementing some features, lowering sometimes needs more liberty
regarding the number of indirection levels. Add a fir.llvm_ptr that has
no constraints.
Allow its usage in fir.coordinate_op, fir.load, and fir.store.
Convert the FIR LLVMPointer to an LLVMPointer in the LLVM dialect.
Reviewed By: clementval
Differential Revision: https://reviews.llvm.org/D113755
Co-authored-by: Jean Perier <jperier@nvidia.com>
As for D113662, this patch just add a place holder for
the fir.global_len operation conversion. This operation
is part of F20xx and is not implemented yet.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D113887
This patch extends the `FIRToLLVMLowering` pass in Flang by adding a
hook to transform `fir.unboxchar` to a sequence of LLVM MLIR
instructions.
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/D113747
Originally written by:
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Fortran defines an ENTRY point name as being pure if its enclosing
subprogram scope defines a pure procedure.
Differential Revision: https://reviews.llvm.org/D113711
Profiling a basic internal real input read benchmark shows some
hot spots in the code used to prepare input for decimal-to-binary
conversion, which is of course where the time should be spent.
The library that implements decimal to/from binary conversions has
been optimized, but not the code in the Fortran runtime that calls it,
and there are some obvious light changes worth making here.
Move some member functions from *.cpp files into the class definitions
of Descriptor and IoStatementState to enable inlining and specialization.
Make GetNextInputBytes() the new basic input API within the
runtime, replacing GetCurrentChar() -- which is rewritten in terms of
GetNextInputBytes -- so that input routines can have the
ability to acquire more than one input character at a time
and amortize overhead.
These changes speed up the time to read 1M random reals
using internal I/O from a character array from 1.29s to 0.54s
on my machine, which on par with Intel Fortran and much faster than
GNU Fortran.
Differential Revision: https://reviews.llvm.org/D113697
The ORDER= argument to the transformational intrinsic function RESHAPE
was being misinterpreted in an inverted way that could be detected only
with 3-d or higher rank array. Fix in both folding and the runtime, and
extend tests.
Differential Revision: https://reviews.llvm.org/D113699
The `fir.select_case` operation is converted to a if-then-else ladder.
Conversion of `fir.select_case` operation with character is not
implemented yet.
This patch is part of the upstreaming effort from fir-dev branch.
Reviewed By: kiranchandramohan, mehdi_amini
Differential Revision: https://reviews.llvm.org/D113484
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
`fir.unbox` operation is an old operation that is no longer required.
There are couple of other operations that can be used to extract
information from a `fir.box` such as `fir.box_rank`, `fir.box_addr`,
`fir.box_dims`.
This was found during the upstreaming process.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D113581
This patch add conversion for primitive operations on complex types.
- fir.addc
- fir.subc
- fir.mulc
- fir.divc
- fir.negc
This adds also the type conversion for !fir.complex<KIND> type.
This patch is part of the upstreaming effort from fir-dev branch.
This patch was updated to avoid failure on windows buildbot.
Flang codegen does not support windows target so we force the test
to use a known target instead.
Reviewed By: kiranchandramohan, rovka
Differential Revision: https://reviews.llvm.org/D113434
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Rewrite function signatures and calls to functions that accept or return
COMPLEX values.
Also teach insert_value and extract_value about the MLIR ComplexType, by
adding AnyComplex to AnyCompositeLike.
This patch is part of the effort for upstreaming the fir-dev branch.
Differential Revision: https://reviews.llvm.org/D113273
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Tim Keith <tkeith@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
This patch adds the basic infrastructure for the TargetRewrite pass,
which rewrites certain FIR dialect operations into target specific
forms. In particular, it converts boxchar function parameters, call
arguments and return values. Other convertions will be included in
future patches.
This patch is part of the effort for upstreaming the fir-dev branch.
Differential Revision: https://reviews.llvm.org/D112910
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Kiran Chandramohan <kiran.chandramohan@arm.com>
Co-authored-by: Tim Keith <tkeith@nvidia.com>
When an array's shape involves references to symbols that are not
invariant in a scope -- the classic example being a dummy array
with an explicit shape involving other dummy arguments -- the
compiler was creating shape expressions that referenced those
symbols. This might be valid if those symbols are somehow
captured and copied at each entry point to a subprogram, and
the copies referenced in the shapes instead, but that's not
the case.
This patch introduces a new expression predicate IsScopeInvariantExpr(),
which defines a class of expressions that contains constant expressions
(in the sense that the standard uses that term) as well as references
to items that may be safely accessed in a context-free way throughout
their scopes. This includes dummy arguments that are INTENT(IN)
and not VALUE, descriptor inquiries into descriptors that cannot
change, and bare LEN type parameters within the definitions of
derived types. The new predicate is then used in shape analysis
to winnow out results that would have otherwise been contextual.
Differential Revision: https://reviews.llvm.org/D113309
V Donaldson