[Debug] [Coroutines] Get rid of DW_ATE_address

Closing https://github.com/llvm/llvm-project/issues/55916

This patch tries to get rid of DW_ATE_address and enhance the test
coverage.

Reviewed By: d

[Debug] [Coroutines] Get rid of DW_ATE_address

Closing https://github.com/llvm/llvm-project/issues/55916

This patch tries to get rid of DW_ATE_address and enhance the test
coverage.

Reviewed By: dblaikie

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

show more ...

[Debug] [Coroutine] Adjust the scope and name for coroutine frame

Previously the scope of debug type of __coro_frame is limited in the
current function. It looked good at the first sight. But it pre

[Debug] [Coroutine] Adjust the scope and name for coroutine frame

Previously the scope of debug type of __coro_frame is limited in the
current function. It looked good at the first sight. But it prevent us
to print the type in splitted functions and other functions. Also the
debug type is different for different coroutine functions. So it makes
sense to rename the debug type to make it related to the function name.

After this patch, we could access the coroutine frame type in a function
by `function_name.coro_frame_ty`.

Reviewed By: dblaikie

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

show more ...

Revert "[Coroutines] Only do symmetric transfer if optimization is on"

This reverts commit 7782e080e80a90f7bb32049beb3787e2118c2251. According
to the discussion of WG21, symmetric transfer is a desi

Revert "[Coroutines] Only do symmetric transfer if optimization is on"

This reverts commit 7782e080e80a90f7bb32049beb3787e2118c2251. According
to the discussion of WG21, symmetric transfer is a desired feature.

show more ...

[llvm] Don't use Optional::getValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

[NFC] Simplify alignment code in CoroFrame

[Coroutines] Only do symmetric transfer if optimization is on

Symmetric transfer is not a part of C++ standards. So the vendors is not
forced to implement it any way. Given the symmetric transfer no

[Coroutines] Only do symmetric transfer if optimization is on

Symmetric transfer is not a part of C++ standards. So the vendors is not
forced to implement it any way. Given the symmetric transfer nowadays is
an optimization. It makes more sense to enable it only if the
optimization is enabled. It is also helpful for the compilation speed in
O0.

show more ...

[NFC][Alignment] Use Align in CoroFrame

[Debug] [Coroutines] Add deref operator for non complex expression

Background:

When we construct coroutine frame, we would insert a dbg.declare
intrinsic for it:
```
%hdl = call void @llvm.coro.beg

[Debug] [Coroutines] Add deref operator for non complex expression

Background:

When we construct coroutine frame, we would insert a dbg.declare
intrinsic for it:
```
%hdl = call void @llvm.coro.begin() ; would return coroutine handle
call void @llvm.dbg.declare(metadata ptr %hdl, metadata
![[DEBUG_VARIABLE: __coro_frame]], metadata !DIExpression())
```

And in the splitted coroutine, it looks like:
```
define void @coro_func.resume(ptr *hdl) {
entry.resume:
call void @llvm.dbg.declare(metadata ptr %hdl, metadata
![[DEBUG_VARIABLE: __coro_frame]], metadata !DIExpression())
}
```

And we would salvage the debug info by inserting a new alloca here:
```
define void @coro_func.resume(ptr %hdl) {
entry.resume:
%frame.debug = alloca ptr
call void @llvm.dbg.declare(metadata ptr %frame.debug, metadata
![[DEBUG_VARIABLE: __coro_frame]], metadata !DIExpression())
store ptr %hdl, %frame.debug
}
```

But now, the problem comes since the `dbg.declare` refers to the address
of that alloca instead of actual coroutine handle. I saw there are codes
to solve the problem but it only applies to complex expression only. I
feel if it is OK to relax the condition to make it work for
`__coro_frame`.

Reviewed By: jmorse

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

show more ...

[llvm] Convert for_each to range-based for loops (NFC)

[coro async] Add code to support dynamic aligment of over-aligned types in async frames

Async context frames are allocated with a maximum alignment. If a type
requests an alignment bigger than that

[coro async] Add code to support dynamic aligment of over-aligned types in async frames

Async context frames are allocated with a maximum alignment. If a type
requests an alignment bigger than that dynamically align the address
in the frame.

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

show more ...

[iwyu] Handle regressions in libLLVM header include

Running iwyu-diff on LLVM codebase since 7030654296a0416bd9402a0278 detected a few
regressions, fixing them.

Differential Revision: https://revie

[iwyu] Handle regressions in libLLVM header include

Running iwyu-diff on LLVM codebase since 7030654296a0416bd9402a0278 detected a few
regressions, fixing them.

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

show more ...

[NFC] [Coroutines] Remove EnableReuseStorageInFrame option

The EnableReuseStorageInFrame option is designed for testing only.
But it is better to use *_PASS_WITH_PARAMS macro to keep consistent with

[NFC] [Coroutines] Remove EnableReuseStorageInFrame option

The EnableReuseStorageInFrame option is designed for testing only.
But it is better to use *_PASS_WITH_PARAMS macro to keep consistent with
other passes.

show more ...

[Coroutines] Don't re-materialize for debug instructions

Re-materialize for debug instructions would cause a different code
generated if we enabled `-g`. This is bad. So we disable to
re-materialize

[Coroutines] Don't re-materialize for debug instructions

Re-materialize for debug instructions would cause a different code
generated if we enabled `-g`. This is bad. So we disable to
re-materialize for debug instructions.

show more ...

[coroutines] Get an IntegerType from the value instead of defaulting to 64 bit

This AliasPtr is being created always from an Int64 even for targets
where 32 bit is the proper type. e.g. “thumbv7-non

[coroutines] Get an IntegerType from the value instead of defaulting to 64 bit

This AliasPtr is being created always from an Int64 even for targets
where 32 bit is the proper type. e.g. “thumbv7-none-linux-android16”.
This causes the assert in the `get` func to fail as we're getting a 32
bit from the APInt.

Fix this by simply always just getting the type from the value instead.

Reviewed By: ChuanqiXu

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

show more ...

[Coroutines] Support opaque pointers in solveTypeName()

As far as I can tell, these names are only intended to be
informative, so just use a generic "PointerType" for opaque pointers.

The code in s

[Coroutines] Support opaque pointers in solveTypeName()

As far as I can tell, these names are only intended to be
informative, so just use a generic "PointerType" for opaque pointers.

The code in solveDIType() also treats pointers as basic types (and
does not try to encode the pointed-to type further), so I believe
this should be fine.

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

show more ...

[CoroFrame] Avoid pointer element type access for swifterror

These must have pointer-to-pointer type, and with opaque pointers
we don't care about the specific pointer type anymore.

[Coroutines] Allow FramePtr to be an Argument

With opaque pointers, after splitRetconCoroutine() the FramePtr
may be an Argument rather than an Instruction. With typed pointers,
this currently doesn

[Coroutines] Allow FramePtr to be an Argument

With opaque pointers, after splitRetconCoroutine() the FramePtr
may be an Argument rather than an Instruction. With typed pointers,
this currently doesn't happen because the FramePtr would be a
bitcast instruction.

Fix this by making FramePtr a Value and adding a helper for the
"after FramePtr" insertion point, which would be the start of the
function in the Argument case.

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

show more ...

[CoroFrame] Remove unused insertSpills() return value (NFC)

[debug-info] If one sees a spill with a dbg.addr use, salvageDebugInfo upon it and don't hoist it.

This ensures that if we have a dbg.addr in a coroutine funclet that is on one of
our function argum

[debug-info] If one sees a spill with a dbg.addr use, salvageDebugInfo upon it and don't hoist it.

This ensures that if we have a dbg.addr in a coroutine funclet that is on one of
our function arguments, that the dbg.addr is not mapped to undef and also that
later it isn't hoisted to the front of the basic block. Instead it remains at
its original cloned location.

rdar://83957028

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

show more ...

[CoroFrame][OpaquePtr] Remove getPointerElementType() call

Get it from the byval type instead.

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avo

Cleanup header dependencies in LLVMCore

Based on the output of include-what-you-use.

This is a big chunk of changes. It is very likely to break downstream code
unless they took a lot of care in avoiding hidden ehader dependencies, something
the LLVM codebase doesn't do that well :-/

I've tried to summarize the biggest change below:

- llvm/include/llvm-c/Core.h: no longer includes llvm-c/ErrorHandling.h
- llvm/IR/DIBuilder.h no longer includes llvm/IR/DebugInfo.h
- llvm/IR/IRBuilder.h no longer includes llvm/IR/IntrinsicInst.h
- llvm/IR/LLVMRemarkStreamer.h no longer includes llvm/Support/ToolOutputFile.h
- llvm/IR/LegacyPassManager.h no longer include llvm/Pass.h
- llvm/IR/Type.h no longer includes llvm/ADT/SmallPtrSet.h
- llvm/IR/PassManager.h no longer includes llvm/Pass.h nor llvm/Support/Debug.h

And the usual count of preprocessed lines:
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/IR/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 6400831
after: 6189948

200k lines less to process is no that bad ;-)

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup

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

show more ...

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecatin

[NFC] Remove uses of PointerType::getElementType()

Instead use either Type::getPointerElementType() or
Type::getNonOpaquePointerElementType().

This is part of D117885, in preparation for deprecating the API.

show more ...

[NFC] [Coroutines] Rename ReuseFrameSlot to OptimizeFrame

We could use the variable as a flag to indicate if the optimization
is on.

[coro async] Don't use lifetime.start based alloca localization for ABI.Async/ABI.Retcon

Infinite loops can lead to an IR representation where the lifetime.end
intrinsice is missing. The code to do

[coro async] Don't use lifetime.start based alloca localization for ABI.Async/ABI.Retcon

Infinite loops can lead to an IR representation where the lifetime.end
intrinsice is missing. The code to do lifetime based optimization then
fails to see that an address escapes (is life) accross a supspend.

Eventually, we could detect such situations and disable it under more narrow
circumstances. For now, do the correct thing.

rdar://83635953

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

show more ...