[IR] Convert from nocapture to captures(none) (#123181)

This PR removes the old `nocapture` attribute, replacing it with the new
`captures` attribute introduced in #116990. This change is
intended

[IR] Convert from nocapture to captures(none) (#123181)

This PR removes the old `nocapture` attribute, replacing it with the new
`captures` attribute introduced in #116990. This change is
intended to be essentially NFC, replacing existing uses of `nocapture`
with `captures(none)` without adding any new analysis capabilities.
Making use of non-`none` values is left for a followup.

Some notes:
* `nocapture` will be upgraded to `captures(none)` by the bitcode
reader.
* `nocapture` will also be upgraded by the textual IR reader. This is to
make it easier to use old IR files and somewhat reduce the test churn in
this PR.
* Helper APIs like `doesNotCapture()` will check for `captures(none)`.
* MLIR import will convert `captures(none)` into an `llvm.nocapture`
attribute. The representation in the LLVM IR dialect should be updated
separately.

show more ...

[NFC][DebugInfo] Rewrite more call-sites to insert with iterators (#124288)

As part of the "RemoveDIs" work to eliminate debug intrinsics, we're
replacing methods that use Instruction*'s as position

[NFC][DebugInfo] Rewrite more call-sites to insert with iterators (#124288)

As part of the "RemoveDIs" work to eliminate debug intrinsics, we're
replacing methods that use Instruction*'s as positions with iterators. The
call-sites updated in this patch are those where the dyn_cast_or_null cast
utility doesn't compose well with iterator insertion. It can distinguish
between nullptr and a "present" (non-null) Instruction pointer, but not
between a legal and illegal instruction iterator. This can lead to
end-iterator dereferences and thus crashes.

We can improve this in the future (as parent-pointers can now be accessed
from ilist nodes), but for the moment, add explicit tests for end()
iterators at the five call sites affected by this.

show more ...

[NFC][DebugInfo] Make some block-start-position methods return iterators (#124287)

As part of the "RemoveDIs" work to eliminate debug intrinsics, we're
replacing methods that use Instruction*'s as

[NFC][DebugInfo] Make some block-start-position methods return iterators (#124287)

As part of the "RemoveDIs" work to eliminate debug intrinsics, we're
replacing methods that use Instruction*'s as positions with iterators. A
number of these (such as getFirstNonPHIOrDbg) are sufficiently
infrequently used that we can just replace the pointer-returning version
with an iterator-returning version, hopefully without much/any
disruption.

Thus this patch has getFirstNonPHIOrDbg and
getFirstNonPHIOrDbgOrLifetime return an iterator, and updates all
call-sites. There are no concerns about the iterators returned being
converted to Instruction*'s and losing the debug-info bit: because the
methods skip debug intrinsics, the iterator head bit is always false
anyway.

show more ...

[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)

As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and sim

[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)

As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and similar feed into
instruction insertion positions. Call-sites where that's necessary were
updated a year ago; but to ensure some type safety however, we'd like to
have all calls to moveBefore use iterators.

This patch adds a (guaranteed dereferenceable) iterator-taking
moveBefore, and changes a bunch of call-sites where it's obviously safe
to change to use it by just calling getIterator() on an instruction
pointer. A follow-up patch will contain less-obviously-safe changes.

We'll eventually deprecate and remove the instruction-pointer
insertBefore, but not before adding concise documentation of what
considerations are needed (very few).

show more ...

[Coroutines][NFC] Refactor CoroCloner (#116885)

* Move CoroCloner to its own header. For now, the header is located in llvm/lib/Transforms/Coroutines
* Change private to protected to allow inherita

[Coroutines][NFC] Refactor CoroCloner (#116885)

* Move CoroCloner to its own header. For now, the header is located in llvm/lib/Transforms/Coroutines
* Change private to protected to allow inheritance
* Create CoroSwitchCloner and move some of the switch specific code into this cloner. More code will follow in later commits.

show more ...

[Transforms] Remove unused includes (NFC) (#115263)

Identified with misc-include-cleaner.

[IR] Remove some uses of StructType::setBody. NFC. (#113685)

It is simple to create the struct body up front, now that we have
transitioned to opaque pointers.

[Coroutines] Move util headers to include/llvm (#111599)

Plugin libraries that use coroutines can do so right now, however, to
provide their own ABI they need to be able to use various headers, som

[Coroutines] Move util headers to include/llvm (#111599)

Plugin libraries that use coroutines can do so right now, however, to
provide their own ABI they need to be able to use various headers, some
of which such are required (such as the ABI header). This change exposes
the coro utils and required headers by moving them to
include/llvm/Transforms/Coroutines. My experience with our out-of-tree
plugin ABI has been that at least these headers are needed. The headers
moved are:
* ABI.h (ABI object)
* CoroInstr.h (helpers)
* Coroshape.h (Shape object)
* MaterializationUtils.h (helpers)
* SpillingUtils.h (helpers)
* SuspendCrossingInfo.h (analysis)

This has no code changes other than those required to move the headers
and these are:
* include guard name changes
* include path changes
* minor clang-format induced changes
* removal of LLVM_LIBRARY_VISIBILITY

show more ...

[Coroutines] Avoid repeated hash lookups (NFC) (#111617)

[Coroutines] Move OptimizeFrame out of Shape (#111017)

* OptimizeFrame is not really a part of the Coroutine Shape info, rather
it is specifically for the addFieldForAllocas method called indirectly

[Coroutines] Move OptimizeFrame out of Shape (#111017)

* OptimizeFrame is not really a part of the Coroutine Shape info, rather
it is specifically for the addFieldForAllocas method called indirectly
by buildCoroutineFrame.
* This patch passes OptimizeFrame directly to buildCoroutineFrame so it
can be provided to addFieldForAllocas instead of keeping it in the
Shape.

Co-authored-by: tnowicki <tnowicki.nowicki@amd.com>

show more ...

[Coroutines] ABI Objects to improve code separation between different ABIs, users and utilities. (#109713)

This patch re-lands https://github.com/llvm/llvm-project/pull/109338 and
fixes the various

[Coroutines] ABI Objects to improve code separation between different ABIs, users and utilities. (#109713)

This patch re-lands https://github.com/llvm/llvm-project/pull/109338 and
fixes the various test failures.

--- Original description ---

* Adds an ABI object class hierarchy to implement the coroutine ABIs
(Switch, Asyc, and Retcon{Once})
* The ABI object improves the separation of the code related to users,
ABIs and utilities.
* No code changes are required by any existing users.
* Each ABI overrides delegate methods for initialization, building the
coroutine frame and splitting the coroutine, other methods may be added
later.
* CoroSplit invokes a generator lambda to instantiate the ABI object and
calls the ABI object to carry out its primary operations. In a follow-up
change this will be used to instantiated customized ABIs according to a
new intrinsic llvm.coro.begin.custom.abi.
* Note, in a follow-up change additional constructors will be added to
the ABI objects (Switch, Asyc, and AnyRetcon) to allow a set of
generator lambdas to be passed in from a CoroSplit constructor that will
also be added. The init() method is separate from the constructor to
avoid duplication of its code. It is a virtual method so it can be
invoked by CreateAndInitABI or potentially CoroSplit::run(). I wasn't
sure if we should call init() from within CoroSplit::run(),
CreateAndInitABI, or perhaps hard code a call in each constructor. One
consideration is that init() can change the IR, so perhaps it should
appear in CoroSplit::run(), but this looks a bit odd. Invoking init() in
the constructor would result in the call appearing 4 times per ABI
(after adding the new constructors). Invoking it in CreateAndInitABI
seems to be a balance between these.

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057

show more ...

Revert "[Coroutines] ABI Objects to improve code separation between different ABIs, users and utilities. (#109338)"

This reverts commit 2e414799d0ad511cd7999895014a2cae2ea5e3e3.

Reason: buildbot br

Revert "[Coroutines] ABI Objects to improve code separation between different ABIs, users and utilities. (#109338)"

This reverts commit 2e414799d0ad511cd7999895014a2cae2ea5e3e3.

Reason: buildbot breakage
(https://lab.llvm.org/buildbot/#/builders/51/builds/4105)
(This was the only new CL.)

/home/b/sanitizer-aarch64-linux/build/llvm-project/llvm/lib/Transforms/Coroutines/ABI.h:71:31: error: 'llvm::coro::AsyncABI' has virtual functions but non-virtual destructor [-Werror,-Wnon-virtual-dtor]
71 | class LLVM_LIBRARY_VISIBILITY AsyncABI : public BaseABI {

etc.

show more ...

[Coroutines] ABI Objects to improve code separation between different ABIs, users and utilities. (#109338)

* Adds an ABI object class hierarchy to implement the coroutine ABIs
(Switch, Asyc, and Re

[Coroutines] ABI Objects to improve code separation between different ABIs, users and utilities. (#109338)

* Adds an ABI object class hierarchy to implement the coroutine ABIs
(Switch, Asyc, and Retcon{Once})
* The ABI object improves the separation of the code related to users,
ABIs and utilities.
* No code changes are required by any existing users.
* Each ABI overrides delegate methods for initialization, building the
coroutine frame and splitting the coroutine, other methods may be added
later.
* CoroSplit invokes a generator lambda to instantiate the ABI object and
calls the ABI object to carry out its primary operations.

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057

show more ...

[Coroutines] Move materialization code into its own utils (#108240)

* Move materialization out of CoroFrame to MaterializationUtils.h
* Move spill related utilities that were used by materializatio

[Coroutines] Move materialization code into its own utils (#108240)

* Move materialization out of CoroFrame to MaterializationUtils.h
* Move spill related utilities that were used by materialization to
SpillUtils
* Move isSuspendBlock (needed by materialization) to CoroInternal

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057

show more ...

[Coroutines] Verify normalization was not missed (#108096)

* Add asserts to verify normalization of the coroutine happened.
* This will be important when normalization becomes part of an ABI
objec

[Coroutines] Verify normalization was not missed (#108096)

* Add asserts to verify normalization of the coroutine happened.
* This will be important when normalization becomes part of an ABI
object.

--- From a previous discussion here
https://github.com/llvm/llvm-project/pull/108076

Normalization performs these important steps:

split around each suspend, this adds BBs before/after each suspend so
each suspend now exists in its own block.
split around coro.end (similar to above)
break critical edges and add single-edge phis in the new blocks (also
removing other single-edge phis).
Each of these things can individually be tested
A) Check that each suspend is the only inst in its BB
B) Check that coro.end is the only inst in its BB
C) Check that each edge of a multi-edge phis is preceded by single-edge
phi in an immediate pred

For 1) and 2) I believe the purpose of the transform is in part for
suspend crossing info's analysis so it can specifically 'mark' the
suspend blocks and identify the end of the coroutine. There are some
existing places within suspend crossing info that visit the CoroSuspends
and CoroEnds so we could check A) and B) there.

For 3) I believe the purpose of this transform is for insertSpills to
work properly. Infact there is already a check for the result of this
transform!

assert(PN->getNumIncomingValues() == 1 &&
"unexpected number of incoming "
"values in the PHINode");

I think to verify the result of normalization we just need to add checks
A) and B) to suspend crossing info.

show more ...

[Coroutines] Split buildCoroutineFrame into normalization and frame building (#108076)

* Split buildCoroutineFrame into code related to normalization and code
related to actually building the corou

[Coroutines] Split buildCoroutineFrame into normalization and frame building (#108076)

* Split buildCoroutineFrame into code related to normalization and code
related to actually building the coroutine frame.
* This will enable future specialization of buildCoroutineFrame for
different ABIs while the normalization can be done by splitCoroutine
prior to calling buildCoroutineFrame.

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057

show more ...

[Coroutines] Move spill related methods to a Spill utils (#107884)

* Move code related to spilling into SpillUtils to help cleanup
CoroFrame

See RFC for more info:
https://discourse.llvm.org/t/

[Coroutines] Move spill related methods to a Spill utils (#107884)

* Move code related to spilling into SpillUtils to help cleanup
CoroFrame

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057

show more ...

Add DIExpression::foldConstantMath to CoroSplit (#107933)

The CoroSplit pass has it's own salvageDebugInfo implementation and it's
DIExpressions do not get folded. Add a call to
DIExpression::fold

Add DIExpression::foldConstantMath to CoroSplit (#107933)

The CoroSplit pass has it's own salvageDebugInfo implementation and it's
DIExpressions do not get folded. Add a call to
DIExpression::foldConstantMath in the CoroSplit pass to reduce the size
of those DIExpressions.

[The compile time tracker shows no significant increase in compile time
either.](https://llvm-compile-time-tracker.com/compare.php?from=bdf02249e7f8f95177ff58c881caf219699acb98&to=e1c1c1759c06bc4c42f79eebdb0e3cd45219cef4&stat=instructions:u)

rdar://134675402

show more ...

[Coroutines] Move the SuspendCrossingInfo analysis helper into its own header/source (#106306)

* Move the SuspendCrossingInfo analysis helper into its own
header/source

See RFC for more info:
h

[Coroutines] Move the SuspendCrossingInfo analysis helper into its own header/source (#106306)

* Move the SuspendCrossingInfo analysis helper into its own
header/source

See RFC for more info:
https://discourse.llvm.org/t/rfc-abi-objects-for-coroutines/81057

Co-authored-by: tnowicki <tnowicki.nowicki@amd.com>

show more ...

[Coroutines] Salvage the debug information for coroutine frames within optimizations

This patch tries to salvage the debug information for the coroutine
frames within optimizations by creating the h

[Coroutines] Salvage the debug information for coroutine frames within optimizations

This patch tries to salvage the debug information for the coroutine
frames within optimizations by creating the help alloca varaibles with
optimizations too. We didn't do this when I implement it initially. I
roughtly remember the reason was, we feel the additional help alloca
variable may pessimize the performance, which is almost the most
important thing under optimizations. But now, it looks like the new
inserted help alloca variables can be optimized out by the following
optimizations. So it looks like the time to make it available within
optimizations.

And also, it looks like the following optimizations will convert the
generated dbg.declare instrinsic into dbg.value intrinsic within
optimizations.

In LLVM's test, there is a slightly regression
that a dbg.declare for the promise object failed to be remained after
this change. But it looks like we won't have a chance to see dbg.declare
for the promise object when we split the coroutine as that dbg.declare
will be converted into a dbg.value in early stage.

So everything looks fine.

show more ...

[llvm/llvm-project][Coroutines] Improve debugging and minor refactoring (#104642)

No Functional Changes

* Fix comments in several places
* Instead of using BB-getName() (in dump methods) use
ge

[llvm/llvm-project][Coroutines] Improve debugging and minor refactoring (#104642)

No Functional Changes

* Fix comments in several places
* Instead of using BB-getName() (in dump methods) use
getBasicBlockLabel. This fixes the poor output of the dumped info that
resulted in missing BB labels.
* Use RPO when dumping SuspendCrossingInfo. Without this the dump order
is determined by the ptr addresses and so is not consistent from run to
run making IR diffs difficult to read.
* Inference -> Interference
* Pull the logic that determines insertion location out of insertSpills
and into getSpillInsertionPt, to differentiate between these two
operations.
* Use Shape getters for CoroId instead of getting it manually.

---------

Co-authored-by: tnowicki <tnowicki.nowicki@amd.com>

show more ...

[Coroutines] [NFCI] Don't search the DILocalVariable for __promise when constructing the debug varaible for __coro_frame (#105626)

As the title mentioned, do not search for the DILocalVariable for

[Coroutines] [NFCI] Don't search the DILocalVariable for __promise when constructing the debug varaible for __coro_frame (#105626)

As the title mentioned, do not search for the DILocalVariable for
__promise when constructing the debug variable for __coro_frame.

This should make sense because the debug variable of `__coro_frame`
shouldn't dependent on the debug variable of `__promise`. And actually,
it is not. Currently, we search the debug variable for `__promise` only
because we want to get the debug location and the debug scope for the
`__promise`. However, we can construct the debug location directly from
the debug scope of the being compiled function. Then it is not necessary
any more to search the `__promise` variable.

And this patch makes the codes to construct the debug variable for
`__coro_frame` to be more stable. Now we will always be able to
construct the debug variable for the coroutine frame no matter if we
found the debug variable for the __promise or not.

This patch is not strictly NFC but it is intended to not affect any end
users.

show more ...

Revert "[Coroutines] [NFCI] Don't search the DILocalVariable for __promise when constructing the debug varaible for __coro_frame"

This reverts commit 08a0dece2b2431db8abe650bb43cba01e781e1ce.

This

Revert "[Coroutines] [NFCI] Don't search the DILocalVariable for __promise when constructing the debug varaible for __coro_frame"

This reverts commit 08a0dece2b2431db8abe650bb43cba01e781e1ce.

This series of commits causes Clang crashes. The reproducer is posted on
https://github.com/llvm/llvm-project/commit/08a0dece2b2431db8abe650bb43cba01e781e1ce.

show more ...

Revert "[Coroutines] Fix -Wunused-variable in CoroFrame.cpp (NFC)"

This reverts commit d48b807aa8abd1cbfe8ac5d1ba27b8b3617fc5e6.

This series of commits causes Clang crashes. The reproducer is poste

Revert "[Coroutines] Fix -Wunused-variable in CoroFrame.cpp (NFC)"

This reverts commit d48b807aa8abd1cbfe8ac5d1ba27b8b3617fc5e6.

This series of commits causes Clang crashes. The reproducer is posted on
https://github.com/llvm/llvm-project/commit/08a0dece2b2431db8abe650bb43cba01e781e1ce

show more ...

Revert "[Coroutines] Salvage the debug information for coroutine frames within optimizations"

This reverts commit 522c253f47ea27d8eeb759e06f8749092b1de71e.

This series of commits causes Clang crash

Revert "[Coroutines] Salvage the debug information for coroutine frames within optimizations"

This reverts commit 522c253f47ea27d8eeb759e06f8749092b1de71e.

This series of commits causes Clang crashes. The reproducer is posted on
https://github.com/llvm/llvm-project/commit/08a0dece2b2431db8abe650bb43cba01e781e1ce.

show more ...