Fix https://github.com/llvm/llvm-project/issues/56532
Effectively, this reverts behavior introduced in https://reviews.llvm.org/D117087,
which did two things:
1. Change delayed to early conversion of return object.
2. Introduced RVO possibilities because of early conversion.
This patches fixes (1) and removes (2). I already worked on a follow up for (2)
in a separated patch. I believe it's important to split these two because if the RVO
causes any problems we can explore reverting (2) while maintaining (1).
Notes on some testcase changes:
- `pr59221.cpp` changed to `-O1` so we can check that the front-end honors
the value checked for. Sounds like `-O3` without RVO is more likely
to work with LLVM optimizations...
- Comment out delete members `coroutine-no-move-ctor.cpp` since behavior
now requires copies again.
Differential Revision: https://reviews.llvm.org/D145639
This reverts commit 54225c457a336b1609c6d064b2b606a9238a28b9.
The lack of RVO causes compile errors in our code.
Reverting to unblock our integrate.
See D145639 for full discussion.
Fix https://github.com/llvm/llvm-project/issues/56532
Effectively, this reverts behavior introduced in https://reviews.llvm.org/D117087,
which did two things:
1. Change delayed to early conversion of return object.
2. Introduced RVO possibilities because of early conversion.
This patches fixes (1) and removes (2). I already worked on a follow up for (2)
in a separated patch. I believe it's important to split these two because if the RVO
causes any problems we can explore reverting (2) while maintaining (1).
Notes on some testcase changes:
- `pr59221.cpp` changed to `-O1` so we can check that the front-end honors
the value checked for. Sounds like `-O3` without RVO is more likely
to work with LLVM optimizations...
- Comment out delete members `coroutine-no-move-ctor.cpp` since behavior
now requires copies again.
Differential Revision: https://reviews.llvm.org/D145639
Close https://github.com/llvm/llvm-project/issues/59221.
The root cause for the problem is that we marked the parameter of the
resume/destroy functions as noalias previously. But this is not true.
See https://github.com/llvm/llvm-project/issues/59221 for the details.
Long story short, for this C++ program
(https://compiler-explorer.com/z/6qGcozG93), the optimized frame will be
something like:
```
struct test_frame {
void (*__resume_)(), // a function pointer points to the
`test.resume` function, which can be imaged as the test() function in
the example.
....
struct a_frame {
...
void **caller; // may points to test_frame at runtime.
};
};
```
And the function a and function test looks just like:
```
define i32 @a(ptr noalias %alloc_8) {
%alloc_8_16 = getelementptr ptr, ptr %alloc_8, i64 16
store i32 42, ptr %alloc_8_16, align 8
%alloc_8_8 = getelementptr ptr, ptr %alloc_8, i64 8
%alloc = load ptr, ptr %alloc_8_8, align 8
%p = load ptr, ptr %alloc, align 8
%r = call i32 %p(ptr %alloc)
ret i32 %r
}
define i32 @b(ptr %p) {
entry:
%alloc = alloca [128 x i8], align 8
%alloc_8 = getelementptr ptr, ptr %alloc, i64 8
%alloc_8_8 = getelementptr ptr, ptr %alloc_8, i64 8
store ptr %alloc, ptr %alloc_8_8, align 8
store ptr %p, ptr %alloc, align 8
%r = call i32 @a(ptr nonnull %alloc_8)
ret i32 %r
}
```
Here inside the function `a`, we can access the parameter `%alloc_8` by
`%alloc` and we pass `%alloc` to an unknown function. So it breaks the
assumption of `noalias` parameter.
Note that although only CoroElide optimization can put a frame inside
another frame directly, the following case is not valid too:
```
struct test_frame {
....
void **a_frame; // may points to a_frame at runtime.
};
struct a_frame {
void **caller; // may points to test_frame at runtime.
};
```
Since the C++ language allows the programmer to get the address of
coroutine frames, we can't assume the above case wouldn't happen in the
source codes. So we can't set the parameter as noalias no matter if
CoroElide applies or not. And for other languages, it may be safe if
they don't allow the programmers to get the address of coroutine frames.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D139295
