History log of /llvm-project/flang/lib/Optimizer/Transforms/ArrayValueCopy.cpp (Results 1 – 25 of 36)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# db791b27 02-Jul-2024 Ramkumar Ramachandra <ramkumar.ramachandra@codasip.com>

mlir/LogicalResult: move into llvm (#97309)

This patch is part of a project to move the Presburger library into
LLVM.


Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5
# fac349a1 28-Apr-2024 Christian Sigg <chsigg@users.noreply.github.com>

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change rem

Reapply "[mlir] Mark `isa/dyn_cast/cast/...` member functions depreca… (#90406)

…ted. (#89998)" (#90250)

This partially reverts commit 7aedd7dc754c74a49fe84ed2640e269c25414087.

This change removes calls to the deprecated member functions. It does
not mark the functions deprecated yet and does not disable the
deprecation warning in TypeSwitch. This seems to cause problems with
MSVC.

show more ...


# 7aedd7dc 26-Apr-2024 dyung <douglas.yung@sony.com>

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on

Revert "[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)" (#90250)

This reverts commit 950b7ce0b88318f9099e9a7c9817d224ebdc6337.

This change is causing build failures on a bot
https://lab.llvm.org/buildbot/#/builders/216/builds/38157

show more ...


# 950b7ce0 26-Apr-2024 Christian Sigg <chsigg@users.noreply.github.com>

[mlir] Mark `isa/dyn_cast/cast/...` member functions deprecated. (#89998)

See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.


# 57b26790 22-Apr-2024 Christian Sigg <chsigg@users.noreply.github.com>

Mark `mlir::Value::isa/dyn_cast/cast/...` member functions deprecated. (#89238)

See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443/4


# 971237da 17-Apr-2024 jeanPerier <jperier@nvidia.com>

[flang] Retain internal and BIND(C) host procedure link in FIR (#87796)

Currently, it is not possible to find back which fun.func is the host
procedure of some internal procedure because the mangli

[flang] Retain internal and BIND(C) host procedure link in FIR (#87796)

Currently, it is not possible to find back which fun.func is the host
procedure of some internal procedure because the mangling of the
internal procedure does not contain info about the BIND(C) name of the
host.
This info may be useful to ensure dwarf DW_TAG_subprogram of internal
procedures are nested under DW_TAG_subprogram of host procedures for
instance.

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3
# 7d9c38a0 12-Feb-2024 Valentin Clement (バレンタイン クレメン) <clementval@gmail.com>

[flang][NFC] Remove hardcoded attr name for fir.global op (#81347)

These hardcoded attribute name are a leftover from the upstreaming
period when there was no way to get the attribute name without

[flang][NFC] Remove hardcoded attr name for fir.global op (#81347)

These hardcoded attribute name are a leftover from the upstreaming
period when there was no way to get the attribute name without an
instance of the operation. It is since possible to do without them and
they should be removed to avoid duplication.

This PR cleanup the fir.global op of these hardcoded attribute name and
use their generated getters. Some other PRs will follow to cleanup other
operations.

show more ...


Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1
# 27cfe7a0 24-Jan-2024 jeanPerier <jperier@nvidia.com>

[flang] Set assumed-size last extent to -1 (#79156)

Currently lowering sets the extents of assumed-size array to "undef"
which was OK as long as the value was not expected to be read.

But when i

[flang] Set assumed-size last extent to -1 (#79156)

Currently lowering sets the extents of assumed-size array to "undef"
which was OK as long as the value was not expected to be read.

But when interfacing with the runtime and when passing assumed-size to
assumed-rank, this last extent may be read and must be -1 as specified
in the BIND(C) case in 18.5.3 point 5.

Set this value to -1, and update all the lowering code that was looking
for an undef defining op to identify assumed-size: much safer to
propagate and use semantic info here, the previous check actually did
not work if the array was used in an internal procedure (defining op not
visible anymore).

@clementval and @agozillon, I left assumed-size extent to zero in the
acc/omp bounds op as it was, please double check that is what you want
(I can imagine -1 may create troubles here, and 0 makes some sense as it
would lead to no data transfer).

This also allows removing special cases in UBOUND/LBOUND lowering.

Also disable allocation of cray pointee. This was never intended and
would now lead to crashes with the -1 value for assumed-size cray
pointee.

show more ...


Revision tags: llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, 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
# 53cc33b0 01-Jun-2023 Tom Eccles <tom.eccles@arm.com>

[flang] Store KindMapping by value in FirOpBuilder

Previously only a constant reference was stored in the FirOpBuilder.
However, a lot of code was merged using

FirOpBuilder builder{rewriter, getKin

[flang] Store KindMapping by value in FirOpBuilder

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

show more ...


Revision tags: 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
# b07ef9e7 09-Mar-2023 Renaud-K <rkauffmann@nvidia.com>

Break circular dependency between FIR dialect and utilities


Revision tags: llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init
# 59b18b5c 21-Jan-2023 Slava Zakharin <szakharin@nvidia.com>

[flang] Avoid unnecessary temporaries in ArrayValueCopy.

Assume no conflict between pointer arrays and arrays without the target
attribute, if the fact of an array not having the target attribute
ca

[flang] Avoid unnecessary temporaries in ArrayValueCopy.

Assume no conflict between pointer arrays and arrays without the target
attribute, if the fact of an array not having the target attribute
can be reliably computed.

This change speeds up SPEC CPU2017/527.cam from 2.5k seconds to 880 seconds
on Icelake, and makes further performance investigation easier.

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

show more ...


Revision tags: llvmorg-15.0.7
# 93129ca8 20-Dec-2022 Jean Perier <jperier@nvidia.com>

[flang] Do not convey captured globals through host link

Addresses and properties (bounds, length parameters) of host
variables associated in an internal procedure were all passed via
an extra tuple

[flang] Do not convey captured globals through host link

Addresses and properties (bounds, length parameters) of host
variables associated in an internal procedure were all passed via
an extra tuple argument of the internal procedure.
This extra tuple is in general an overhead: it must be created and
passed, and require creating thunks when taking the address of the
internal procedure.
This patch allows not using the tuple for host global variables
(from modules, common block, or local saved variables) since they can
be instantiated from the fir.global symbol in the internal procedure
instead.
Add a fir.internal_proc attribute to mlir::FuncOp for internal procedures
so that ArrayValueCopy can still detect internal procedures even if they
do not have a tuple argument.

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

show more ...


# 11760b3a 06-Dec-2022 Valentin Clement <clementval@gmail.com>

[flang] Set correct box type when emboxing temporary in array value copy pass

In some cases, the base type is already a fir.box type. This patch updates
the code to set the result box type to fir.bo

[flang] Set correct box type when emboxing temporary in array value copy pass

In some cases, the base type is already a fir.box type. This patch updates
the code to set the result box type to fir.box<T>, where T is the type
of the allocated temp.

This was reported in https://github.com/llvm/llvm-project/issues/59342

Reviewed By: jeanPerier, tblah

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

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2
# 6c8d8d10 29-Sep-2022 Jakub Kuderski <kubak@google.com>

[flang][mlir][arith] Fix flang build after dialect renaming

Tested with `ninja check-flang`


Revision tags: llvmorg-15.0.1, llvmorg-15.0.0
# 67d0d7ac 31-Aug-2022 Michele Scuttari <michele.scuttari@outlook.com>

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow drop

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.

Reviewed By: mehdi_amini, rriddle

Differential Review: https://reviews.llvm.org/D132838

show more ...


# 039b969b 30-Aug-2022 Michele Scuttari <michele.scuttari@outlook.com>

Revert "[MLIR] Update pass declarations to new autogenerated files"

This reverts commit 2be8af8f0e0780901213b6fd3013a5268ddc3359.


# 2be8af8f 30-Aug-2022 Michele Scuttari <michele.scuttari@outlook.com>

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow drop

[MLIR] Update pass declarations to new autogenerated files

The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure.

Reviewed By: mehdi_amini, rriddle

Differential Review: https://reviews.llvm.org/D132838

show more ...


Revision tags: llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 906784a3 12-Jul-2022 Jean Perier <jperier@nvidia.com>

[flang] move getKindMapping() calls out of FIROpBuilder ctor calls

FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping()
call is made inside the ctor call, the lifetime of this

[flang] move getKindMapping() calls out of FIROpBuilder ctor calls

FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping()
call is made inside the ctor call, the lifetime of this reference may
be as short as the ctor call (at least with when building flang in
release mode with clang 8). This can cause segfaults when later using
the FirOpBuilder.

Ensure the kindMap passed to the FirOpBuilder ctor is the same as the
FirOpBuilder.

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

show more ...


# 73026a4f 01-Jul-2022 Slava Zakharin <szakharin@nvidia.com>

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

[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

show more ...


# 649439e7 29-Jun-2022 Valentin Clement <clementval@gmail.com>

[flang] Fix lowering issue with character temp

- Add verifiers that determine if an Op requires type parameters or
not and checks that the correct number of parameters is specified.

This patch is

[flang] Fix lowering issue with character temp

- Add verifiers that determine if an Op requires type parameters or
not and checks that the correct number of parameters is specified.

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

Reviewed By: PeteSteinfeld

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

show more ...


Revision tags: llvmorg-14.0.6
# 8b68da2c 17-Jun-2022 Alex Zinenko <zinenko@google.com>

[mlir] move SCF headers to SCF/{IR,Transforms} respectively

This aligns the SCF dialect file layout with the majority of the dialects.

Reviewed By: jpienaar

Differential Revision: https://reviews.

[mlir] move SCF headers to SCF/{IR,Transforms} respectively

This aligns the SCF dialect file layout with the majority of the dialects.

Reviewed By: jpienaar

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

show more ...


# 3260d423 14-Jun-2022 Valentin Clement <clementval@gmail.com>

[flang] Avoid losing type parameter information

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

Reviewed By: jeanPerier

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

C

[flang] Avoid losing type parameter information

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

Reviewed By: jeanPerier

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

show more ...


Revision tags: llvmorg-14.0.5
# 5b66cc10 10-Jun-2022 Valentin Clement <clementval@gmail.com>

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

[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

show more ...


Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2
# 58ceae95 18-Apr-2022 River Riddle <riddleriver@gmail.com>

[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace

FuncOp has been moved to the `func` namespace for a little over a month, the
using directive can be dropped now.


Revision tags: llvmorg-14.0.1
# 5e50dd04 31-Mar-2022 River Riddle <riddleriver@gmail.com>

[mlir] Rework the implementation of TypeID

This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implici

[mlir] Rework the implementation of TypeID

This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

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

show more ...


12