History log of /llvm-project/flang/test/Lower/array-temp.f90 (Results 1 – 11 of 11)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6
# a88677ed 10-Dec-2024 Yusuke MINATO <minato.yusuke@fujitsu.com>

Reland "[flang] Integrate the option -flang-experimental-integer-overflow into -fno-wrapv" (#118933)

This relands #110063.
The performance issue on 503.bwaves_r is found not to be related to the
p

Reland "[flang] Integrate the option -flang-experimental-integer-overflow into -fno-wrapv" (#118933)

This relands #110063.
The performance issue on 503.bwaves_r is found not to be related to the
patch, and is resolved by fbd89bcc when LTO is enabled.

show more ...


Revision tags: llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3
# bd6ab32e 28-Oct-2024 Yusuke MINATO <minato.yusuke@fujitsu.com>

Revert "[flang] Integrate the option -flang-experimental-integer-overflow into -fno-wrapv" (#113901)

Reverts llvm/llvm-project#110063 due to the performance regression on
503.bwaves_r in SPEC2017.


# 96bb375f 25-Oct-2024 Yusuke MINATO <minato.yusuke@fujitsu.com>

[flang] Integrate the option -flang-experimental-integer-overflow into -fno-wrapv (#110063)

nsw is now added to do-variable increment when -fno-wrapv is enabled as
GFortran seems to do.
That means

[flang] Integrate the option -flang-experimental-integer-overflow into -fno-wrapv (#110063)

nsw is now added to do-variable increment when -fno-wrapv is enabled as
GFortran seems to do.
That means the option introduced by #91579 isn't necessary any more.

Note that the feature of -flang-experimental-integer-overflow is enabled
by default.

show more ...


Revision tags: llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1
# 06f775a8 28-Feb-2024 jeanPerier <jperier@nvidia.com>

[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 ...


Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# bb6d5c22 05-Jan-2024 Matthias Springer <me@m-sp.org>

[mlir][Transforms] `GreedyPatternRewriteDriver`: Do not CSE constants during iterations (#75897)

The `GreedyPatternRewriteDriver` tries to iteratively fold ops and apply
rewrite patterns to ops. It

[mlir][Transforms] `GreedyPatternRewriteDriver`: Do not CSE constants during iterations (#75897)

The `GreedyPatternRewriteDriver` tries to iteratively fold ops and apply
rewrite patterns to ops. It has special handling for constants: they are
CSE'd and sometimes moved to parent regions to allow for additional
CSE'ing. This happens in `OperationFolder`.

To allow for efficient CSE'ing, `OperationFolder` maintains an internal
lookup data structure to find the existing constant ops with the same
value for each `IsolatedFromAbove` region:
```c++
/// A mapping between an insertion region and the constants that have been
/// created within it.
DenseMap<Region *, ConstantMap> foldScopes;
```

Rewrite patterns are allowed to modify operations. In particular, they
may move operations (including constants) from one region to another
one. Such an IR rewrite can make the above lookup data structure
inconsistent.

We encountered such a bug in a downstream project. This bug materialized
in the form of an op that uses the result of a constant op from a
different `IsolatedFromAbove` region (that is not accessible).

This commit changes the behavior of the `GreedyPatternRewriteDriver`
such that `OperationFolder` is used to CSE constants at the beginning of
each iteration (as the worklist is populated), but no longer during an
iteration. `OperationFolder` is no longer used after populating the
worklist, so we do not have to care about inconsistent state in the
`OperationFolder` due to IR rewrites. The `GreedyPatternRewriteDriver`
now performs the op folding by itself instead of calling
`OperationFolder::tryToFold`.

This change changes the order of constant ops in test cases, but not the
region in which they appear. All broken test cases were fixed by turning
`CHECK` into `CHECK-DAG`.

Alternatives considered: The state of `OperationFolder` could be
partially invalidated with every `notifyOperationModified` notification.
That is more fragile than the solution in this commit because incorrect
rewriter API usage can lead to missing notifications and hard-to-debug
`IsolatedFromAbove` violations. (It did not fix the above mention bug in
a downstream project, which could be due to incorrect rewriter API usage
or due to another conceptual problem that I missed.) Moreover, ops are
frequently getting modified during a greedy pattern rewrite, so we would
likely keep invalidating large parts of the state of `OperationFolder`
over and over.

Migration guide: Turn `CHECK` into `CHECK-DAG` in test cases. Constant
ops are no longer folded during a greedy pattern rewrite. If you rely on
folding (and rematerialization) of constant ops during a greedy pattern
rewrite, turn the folder into a pattern.

show more ...


# 8f3357b7 02-Jan-2024 Peter Klausler <35819229+klausler@users.noreply.github.com>

[flang][runtime] Don't use -1 in I/O API for "default unit" (#76642)

The I/O runtime's API allows -1 to be passed for a unit number in a
READ, WRITE, or PRINT statement, where it gets replaced by 5

[flang][runtime] Don't use -1 in I/O API for "default unit" (#76642)

The I/O runtime's API allows -1 to be passed for a unit number in a
READ, WRITE, or PRINT statement, where it gets replaced by 5 or 6 as
appropriate. This turns out to have been a bad idea, as it prevents the
I/O runtime from detecting and reporting a program's invalid attempt to
use -1 as an I/O unit number. So just pass 5 or 6 as appropriate.

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5
# f35f863a 13-Nov-2023 jeanPerier <jperier@nvidia.com>

[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 ...


Revision tags: llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5
# b90ebbc5 16-Nov-2022 Peter Klausler <pklausler@nvidia.com>

[flang] Fold the RHS of assignment

In order to emit overflow warnings from assignment statements whose
right-hand sides are constants that undergo conversions, run the
right-hand sides of assignment

[flang] Fold the RHS of assignment

In order to emit overflow warnings from assignment statements whose
right-hand sides are constants that undergo conversions, run the
right-hand sides of assignments through constant folding after the
conversions have been made explicit in expression analysis.

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

show more ...


# 4cc9437a 11-Nov-2022 Tom Eccles <tom.eccles@arm.com>

[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 ...


Revision tags: llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 13f9089a 30-Jun-2022 Peixin Qiao <qiaopeixin@huawei.com>

[flang] Fix one corner case in reshape intrinsic

As Fortran 2018 16.9.163, the reshape is the only intrinsic which
requires the shape argument to be rank-one integer array and the SIZE
of it to be o

[flang] Fix one corner case in reshape intrinsic

As Fortran 2018 16.9.163, the reshape is the only intrinsic which
requires the shape argument to be rank-one integer array and the SIZE
of it to be one constant expression. The current expression lowering
converts the shape expression with slice in intrinsic into one box value
with the box element type of unknown extent. However, the genReshape
requires the box element type to be constant size. So, convert the box
value into one with box element type of sequence of 1 x constant. This
corner case is found in cam4 in SPEC 2017
https://github.com/llvm/llvm-project/issues/56140.

Reviewed By: Jean Perier

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

show more ...


# 656b8d6c 27-Jun-2022 Valentin Clement <clementval@gmail.com>

[flang][NFC] Add array lowering tests

These tests were left behind during the upstreaming of parts lowering.

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

Reviewed By: jeanPeri

[flang][NFC] Add array lowering tests

These tests were left behind during the upstreaming of parts lowering.

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

Reviewed By: jeanPerier

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

Co-authored-by: V Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

show more ...