History log of /llvm-project-15.0.7/flang/lib/Optimizer/Builder/Character.cpp (Results 1 – 16 of 16)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, 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, 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, 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, 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, llvmorg-15.0.4, llvmorg-15.0.3, 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, llvmorg-14.0.6, llvmorg-14.0.5
# 5b66cc10 10-Jun-2022 Valentin Clement <[email protected]>

[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 <[email protected]>

Reviewed By: jeanPerier

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

show more ...


Revision tags: llvmorg-14.0.4
# ffc7f9d5 06-May-2022 PeixinQiao <[email protected]>

[flang] Support external procedure passed as actual argument with implicit character type

As Fortran 2018 15.5.2.9 point 2, the actual argument and dummy argument
have the same type and type paramet

[flang] Support external procedure passed as actual argument with implicit character type

As Fortran 2018 15.5.2.9 point 2, the actual argument and dummy argument
have the same type and type parameters and an external function with
assumed character length may be associated with a dummy argument with
explicit character length. As Fortran 2018 15.5.2.9 point 7, if an
external procedure is used as an actual argument, it can be explicitly
declared to have the EXTERNAL attribute. This supports the external
procedure passed as actual argument with implicit character type, either
explicit character length or assumed character length.

Reviewed By: Jean Perier, klausler

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

show more ...


Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 5bc9ee1b 25-Mar-2022 Jean Perier <[email protected]>

[flang][lowering] Handle zero extent case in LBOUND

Follow up of https://reviews.llvm.org/D121488. Ensure lower bounds
are `1` when the related dimension extent is zero. Note that lower
bounds from

[flang][lowering] Handle zero extent case in LBOUND

Follow up of https://reviews.llvm.org/D121488. Ensure lower bounds
are `1` when the related dimension extent is zero. Note that lower
bounds from descriptors are now guaranteed to fulfill this property
after the runtime/codegen patches.

Also fixes explicit shape array extent lowering when instantiating
variables to deal with negative extent cases (issue found while testing
LBOUND edge case). This notably caused allocation crashes when dealing
with automatic arrays with reversed bounds or negative size
specification expression. The standard specifies that the extent of such
arrays is zero. This change has some ripple effect in the current lit
tests.

Add move two helpers as part of this change:
- Add a helper to tell if a fir::ExtendedValue describes an assumed size
array (last dimension extent is unknown to the compiler, both at compile
time and runtime).

- Move and share getIntIfConstant from Character.cpp so that it can be
used elsewhere (NFC).

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

show more ...


# fe252f8e 22-Mar-2022 Valentin Clement <[email protected]>

[flang] Lower boxed procedure

In FIR, we want to wrap function pointers in a special box known as a
boxproc value. Fortran has a limited form of dynamic scoping
[https://tinyurl.com/2p8v2hw7] betwee

[flang] Lower boxed procedure

In FIR, we want to wrap function pointers in a special box known as a
boxproc value. Fortran has a limited form of dynamic scoping
[https://tinyurl.com/2p8v2hw7] between "host procedures" and "internal
procedures". There are a number of implementations possible.

Boxproc typed values abstract away the implementation details of when a
function pointer can be passed directly (as a raw address) and when a
function pointer has to account for the presence of a dynamic scope.
When lowering Fortran syntax to FIR, all function pointers are emboxed
as boxproc values.

When creating LLVM IR, we must strip away the abstraction and produce
low-level LLVM "assembly" code. This patch implements that
transformation as converting the boxproc values to either raw function
pointers or executable trampolines on the stack as needed. The
trampoline then captures the dynamic scope context within an executable
thunk that can be passed instead of the function's raw address.

Some extra handling is required for Fortran functions that return a
character value to deal with LEN values here.

Some of the code in Bridge.cpp and ConvertExpr.cpp and be re-arranged to
faciliate the upstreaming effort.

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

Reviewed By: jeanPerier, PeteSteinfeld

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

Co-authored-by: mleair <[email protected]>
Co-authored-by: Jean Perier <[email protected]>
Co-authored-by: Eric Schweitz <[email protected]>
Co-authored-by: V Donaldson <[email protected]>
Co-authored-by: Kiran Chandramohan <[email protected]>

show more ...


# 518a837e 17-Mar-2022 Valentin Clement <[email protected]>

[flang] Add array constructor lowering tests

This patch adds some tests for the lowering of
array constructors.

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

Reviewed By: PeteS

[flang] Add array constructor lowering tests

This patch adds some tests for the lowering of
array constructors.

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

Reviewed By: PeteSteinfeld

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

Co-authored-by: mleair <[email protected]>
Co-authored-by: Jean Perier <[email protected]>
Co-authored-by: Eric Schweitz <[email protected]>
Co-authored-by: V Donaldson <[email protected]>

show more ...


# 4a3460a7 16-Mar-2022 River Riddle <[email protected]>

[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"

This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes

[mlir:FunctionOpInterface] Rename the "type" attribute to "function_type"

This removes any potential confusion with the `getType` accessors
which correspond to SSA results of an operation, and makes it
clear what the intent is (i.e. to represent the type of the function).

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

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# 092601d4 03-Mar-2022 Andrzej Warzynski <[email protected]>

[flang] Remove 'using namespace mlir;` from header files

Currently, CGOps.h and FIROps.h contain `using namespace mlir;`. Every
file that includes one of these header files (directly and transitivel

[flang] Remove 'using namespace mlir;` from header files

Currently, CGOps.h and FIROps.h contain `using namespace mlir;`. Every
file that includes one of these header files (directly and transitively)
will have the MLIR namespace enabled. With name-clashes within
sub-projects (LLVM and MLIR, MLIR and Flang), this is not desired. Also,
it is not possible to "un-use" a namespace once it is "used". Instead,
we should try to limit `using namespace` to implementation files (i.e.
*.cpp).

This patch removes `using namespace mlir;` from header files and adjusts
other files accordingly. In header and TableGen files, extra namespace
qualifier is added when referring to symbols defined in MLIR. Similar
approach is adopted in source files that didn't require many changes. In
files that would require a lot of changes, `using namespace mlir;` is
added instead.

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

show more ...


# 7e32cada 02-Mar-2022 Valentin Clement <[email protected]>

[flang] Lower inquire statement

This patch adds the lowering of the `inquire` statement.

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

Depends on D120822

Reviewed By: schweitz

[flang] Lower inquire statement

This patch adds the lowering of the `inquire` statement.

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

Depends on D120822

Reviewed By: schweitz

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

Co-authored-by: Jean Perier <[email protected]>

show more ...


Revision tags: llvmorg-14.0.0-rc2
# 149ad3d5 15-Feb-2022 Shraiysh Vaishay <[email protected]>

[flang][mlir][NFC] Replace uses of raw accessors with prefixed accessors

`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.

Reviewed By: c

[flang][mlir][NFC] Replace uses of raw accessors with prefixed accessors

`kEmitAccessorPrefix_Raw ` is being removed, and so updating the
accessors to `kEmitAccessorPrefix_Prefixed`.

Reviewed By: clementval

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

show more ...


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init
# 8e123ca6 31-Jan-2022 River Riddle <[email protected]>

[mlir:Standard] Remove support for creating a `unit` ConstantOp

This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into

[mlir:Standard] Remove support for creating a `unit` ConstantOp

This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into the ecosystem. Given that, as part of
splitting up the standard dialect it's best to just remove this behavior, instead of try
to awkwardly fit it somewhere upstream. Downstream users are encouraged to
define their own operations that clearly can define the semantics of this.

This also uncovered several lingering uses of ConstantOp that weren't
updated to use arith::ConstantOp, and worked during conversions because
the constant was removed/converted into something else before
verification.

See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for more discussion.

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

show more ...


# dec8af70 31-Jan-2022 River Riddle <[email protected]>

[mlir] Move SelectOp from Standard to Arithmetic

This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

Differenti

[mlir] Move SelectOp from Standard to Arithmetic

This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

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

show more ...


# 416e503a 27-Jan-2022 Jean Perier <[email protected]>

[flang] split character procedure arguments in target-rewrite pass

When passing a character procedure as a dummy procedure, the result
length must be passed along the function address. This is to co

[flang] split character procedure arguments in target-rewrite pass

When passing a character procedure as a dummy procedure, the result
length must be passed along the function address. This is to cover
the cases where the dummy procedure is declared with assumed length
inside the scope that will call it (it will need the length to allocate
the result on the caller side).

To be compatible with other Fortran compiler, this length must be
appended after all other argument just like character objects
(fir.boxchar).

A fir.boxchar cannot be used to implement this feature because it
is meant to take an object address, not a function address.

Instead, argument like `tuple<function type, integer type> {fir.char_proc}`
will be recognized as being character dummy procedure in FIR. That way
lowering does not have to do the argument split.

This patch adds tools in Character.h to create this type and tuple
values as well as to recognize them and extract its tuple members.

It also updates the target rewrite pass to split these arguments like
fir.boxchar.

This part is part of fir-dev upstreaming. It was reviwed previously
in: https://github.com/flang-compiler/f18-llvm-project/pull/1393

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

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# ca0ed40e 01-Nov-2021 Mehdi Amini <[email protected]>

Remove builder that takes SSA value instead of Attribute on ExtractValueOp, InsetValueOp, and InsertOnRangeOp

This builder exposed a somehow "unsafe" API: it pretends we can
construct an InsertOnRan

Remove builder that takes SSA value instead of Attribute on ExtractValueOp, InsetValueOp, and InsertOnRangeOp

This builder exposed a somehow "unsafe" API: it pretends we can
construct an InsertOnRangeOp from a range of SSA values, even though
this will crash if these aren't the result of `arith.constant` since
the operation actually needs attribute values (a build method can't
fail gracefully).
That means that the caller must check for the producer, at which
point they can just assemble the attribute array directly and call
the existing builder.

The existing call-sites were even in a worse state here: they would
actually create a constant operation that wouldn't be used and only
serve to carry the attribute through the builder API.

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

show more ...


# 13c31539 21-Oct-2021 Valentin Clement <[email protected]>

[fir] Add Character helper

This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.

Reviewed By: schweitz, awarzynski

Differential Revis

[fir] Add Character helper

This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.

Reviewed By: schweitz, awarzynski

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

Co-authored-by: Jean Perier <[email protected]>
Co-authored-by: Eric Schweitz <[email protected]>
Co-authored-by: V Donaldson <[email protected]>

show more ...


# e4ce9224 21-Oct-2021 Valentin Clement <[email protected]>

[fir] Add Character helper

This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.

Reviewed By: schweitz, awarzynski

Differential Revis

[fir] Add Character helper

This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.

Reviewed By: schweitz, awarzynski

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

Co-authored-by: Jean Perier <[email protected]>
Co-authored-by: Eric Schweitz <[email protected]>
Co-authored-by: V Donaldson <[email protected]>

show more ...


# 02d7089c 20-Oct-2021 Valentin Clement <[email protected]>

[fir] Add Character helper

This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.

Reviewed By: schweitz, awarzynski

Differential Revis

[fir] Add Character helper

This patch is extracted from D111337. It introduce the
CharacterExprHelper that helps dealing with character in FIR.

Reviewed By: schweitz, awarzynski

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

Co-authored-by: Jean Perier <[email protected]>
Co-authored-by: Eric Schweitz <[email protected]>
Co-authored-by: V Donaldson <[email protected]>

show more ...