| Issue |
64317
|
| Summary |
`__builtin_assume` in destructors leads to worse codegen
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
cor3ntin
|
Consider the following C++ code
```cpp
struct S {
S();
~S();
int x = 0;
};
S::~S() {
__builtin_assume(x); // #1
}
void f(int n) {
S s;
if (n == 0)
throw;
else
f(n - 1);
}
```
https://godbolt.org/z/ddchhPssK
If line \#1 is commented, llvm is able to see that `S::~S` does nothing and as such it figures out that `f` requires no cleanup and
not call to `_Unwind_Resume` is performed.
If on the other hand `__builtin_assume(x)` is present - and x is not a constant, then:
* Some IR is created to load `x`
* Llvm does not deduce that S::~S() does nothing
* A landing pad / call to `_Unwind_Resume` is generated.
The outcome of that is that `__builtin_assume` cause significant performance regression compared to identical code without it,
when it appears in cleaning code, because it forces an onerous unwinding in places that may otherwise not need one.
I think I have convinced myself that this is a bug in llvm rather than clang but I'm not completely certain.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
