[flang] optimize array function calls using hlfir.eval_in_mem (#118070)

This patch encapsulate array function call lowering into
hlfir.eval_in_mem and allows directly evaluating the call into the L

[flang] optimize array function calls using hlfir.eval_in_mem (#118070)

This patch encapsulate array function call lowering into
hlfir.eval_in_mem and allows directly evaluating the call into the LHS
when possible.

The conditions are: LHS is contiguous, not accessed inside the function,
it is not a whole allocatable, and the function results needs not to be
finalized. All these conditions are tested in the previous hlfir.eval_in_mem
optimization (#118069) that is leveraging the extension of getModRef to
handle function calls(#117164).

This yields a 25% speed-up on polyhedron channel2 benchmark (from 1min
to 45s measured on an X86-64 Zen 2).

show more ...

[flang][NFC] use llvm.intr.stacksave/restore instead of opaque calls (#108562)

The new LLVM stack save/restore intrinsic operations are more convenient
than function calls because they do not add f

[flang][NFC] use llvm.intr.stacksave/restore instead of opaque calls (#108562)

The new LLVM stack save/restore intrinsic operations are more convenient
than function calls because they do not add function declarations to the
module and therefore do not block the parallelisation of passes.
Furthermore they could be much more easily marked with memory effects
than function calls if that ever proved useful.

This builds on top of #107879.

Resolves #108016

show more ...

[flang] Give internal linkage to internal procedures (#81929)

Internal procedures cannot be called directly from outside the host
procedure, so there is no point giving them external linkage. The o

[flang] Give internal linkage to internal procedures (#81929)

Internal procedures cannot be called directly from outside the host
procedure, so there is no point giving them external linkage. The only
reason flang did is because it is the default in MLIR.

Giving external linkage to them:
- prevents deleting them when not used/inlined by LLVM
- causes bugs with shared libraries (at least on linux x86-64) because
the call to the internal function could lead to a dynamic loader call
that would overwrite r10 register (the static chain pointer) due to
system calls and did not restore (it seems it does not expect r10 to be
used for PLT calls).

This patch gives internal linkage to internal procedures:

Note: the llvm.linkage attribute name cannot be obtained via a
getLinkageAttrName since it is not the same name as the one used in the
LLVM dialect. It is just a placeholder defined in
mlir/lib/Conversion/FuncToLLVM/FuncToLLVM.cpp until the func dialect
gets a real linkage model. So simply avoid hard coding it too many times
in lowering.

show more ...

[flang][NFC] Use hlfir=false and flang-deprecated-no-hlfir in legacy tests (#71957)

Patch 2/3 of the transition step 1 described in

https://discourse.llvm.org/t/rfc-enabling-the-hlfir-lowering-by

[flang][NFC] Use hlfir=false and flang-deprecated-no-hlfir in legacy tests (#71957)

Patch 2/3 of the transition step 1 described in

https://discourse.llvm.org/t/rfc-enabling-the-hlfir-lowering-by-default/72778/7.

All the modified tests are still here since coverage for the direct
lowering to FIR was still needed while it was default. Some already have
an HLFIR version, some have not and will need to be ported in step 2
described in the RFC.

Note that another 147 lit tests use -emit-fir/-emit-llvm outputs but do
not need a flag since the HLFIR/no HLFIR output is the same for what is
being tested.

show more ...

flang: Update stacksave/stackrestore intrinsic uses

Suboptimal fix after 25bc999d1fb2efccc3ece398550af738aea7d310. Ideally
this would go through a builder and use the proper alloca type instead
of u

flang: Update stacksave/stackrestore intrinsic uses

Suboptimal fix after 25bc999d1fb2efccc3ece398550af738aea7d310. Ideally
this would go through a builder and use the proper alloca type instead
of using hardcoded mangled names.

show more ...

[flang] Block construct

A block construct is an execution control construct that supports
declaration scopes contained within a parent subprogram scope or another
block scope. (blocks may be nested.

[flang] Block construct

A block construct is an execution control construct that supports
declaration scopes contained within a parent subprogram scope or another
block scope. (blocks may be nested.) This is implemented by applying
basic scope processing to the block level.

Name uniquing/mangling is extended to support this. The term "block" is
heavily overloaded in Fortran standards. Prior name uniquing used tag `B`
for common block objects. Existing tag choices were modified to free up `B`
for block construct entities, and `C` for common blocks, and resolve
additional issues with other tags. The "old tag -> new tag" changes can
be summarized as:

-> B -- block construct -> new
B -> C -- common block
C -> YI -- intrinsic type descriptor; not currently generated
CT -> Y -- nonintrinsic type descriptor; not currently generated
G -> N -- namelist group
L -> -- block data; not needed -> deleted

Existing name uniquing components consist of a tag followed by a name
from user source code, such as a module, subprogram, or variable name.
Block constructs are different in that they may be anonymous. (Like other
constructs, a block may have a `block-construct-name` that can be used
in exit statements, but this name is optional.) So blocks are given a
numeric compiler-generated preorder index starting with `B1`, `B2`,
and so on, on a per-procedure basis.

Name uniquing is also modified to include component names for all
containing procedures rather than for just the immediate host. This
fixes an existing name clash bug with same-named entities in same-named
host subprograms contained in different-named containing subprograms,
and variations of the bug involving modules and submodules.

F18 clause 9.7.3.1 (Deallocation of allocatable variables) paragraph 1
has a requirement that an allocated, unsaved allocatable local variable
must be deallocated on procedure exit. The following paragraph 2 states:

When a BLOCK construct terminates, any unsaved allocated allocatable
local variable of the construct is deallocated.

Similarly, F18 clause 7.5.6.3 (When finalization occurs) paragraph 3
has a requirement that a nonpointer, nonallocatable object must be
finalized on procedure exit. The following paragraph 4 states:

A nonpointer nonallocatable local variable of a BLOCK construct
is finalized immediately before it would become undefined due to
termination of the BLOCK construct.

These deallocation and finalization requirements, along with stack
restoration requirements, require knowledge of block exits. In addition
to normal block termination at an end-block-stmt, a block may be
terminated by executing a branching statement that targets a statement
outside of the block. This includes

Single-target branch statements:
- goto
- exit
- cycle
- return

Bounded multiple-target branch statements:
- arithmetic goto
- IO statement with END, EOR, or ERR specifiers

Unbounded multiple-target branch statements:
- call with alternate return specs
- computed goto
- assigned goto

Lowering code is extended to determine if one of these branches exits
one or more relevant blocks or other constructs, and adds a mechanism to
insert any necessary deallocation, finalization, or stack restoration
code at the source of the branch. For a single-target branch it suffices
to generate the exit code just prior to taking the indicated branch.
Each target of a multiple-target branch must be analyzed individually.
Where necessary, the code must first branch to an intermediate basic
block that contains exit code, followed by a branch to the original target
statement.

This patch implements an `activeConstructStack` construct exit mechanism
that queries a new `activeConstruct` PFT bit to insert stack restoration
code at block exits. It ties in to existing code in ConvertVariable.cpp
routine `instantiateLocal` which has code for finalization, making block
exit finalization on par with subprogram exit finalization. Deallocation
is as yet unimplemented for subprograms or blocks. This may result in
memory leaks for affected objects at either the subprogram or block level.
Deallocation cases can be addressed uniformly for both scopes in a future
patch, presumably with code insertion in routine `instantiateLocal`.

The exit code mechanism is not limited to block construct exits. It is
also available for use with other constructs. In particular, it is used
to replace custom deallocation code for a select case construct character
selector expression where applicable. This functionality is also added
to select type and associate constructs. It is available for use with
other constructs, such as select rank and image control constructs,
if that turns out to be necessary.

Overlapping nonfunctional changes include eliminating "FIR" from some
routine names and eliminating obsolete spaces in comments.

show more ...

[flang] Set default to -ffpcontract=fast

Following RFC at
https://discourse.llvm.org/t/rfc-ffp-contract-default-value/66301

This adds the `fastmath<contract>` attribute to `fir.call` and some
float

[flang] Set default to -ffpcontract=fast

Following RFC at
https://discourse.llvm.org/t/rfc-ffp-contract-default-value/66301

This adds the `fastmath<contract>` attribute to `fir.call` and some
floating point arithmetic operations (hence the many test changes).
Instead of testing for this specific attribute, I am using a regular
expression to match any attributes.

show more ...

[flang] Make sure dynamic extents and length are rounded to 0 if negative

Function returning CHARACTER with adjustable length or dynamic arrays
can have negative length or extents passed to them. Th

[flang] Make sure dynamic extents and length are rounded to 0 if negative

Function returning CHARACTER with adjustable length or dynamic arrays
can have negative length or extents passed to them. This patch makes sure
any negative inputs is rounded to 0.

Reviewed By: vdonaldson

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

show more ...

Fixes a performance problem with lowering of forall loops and creating
too many temporaries.

Fix clang-format errors.

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