https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108217
Josh Haberman <jhaberman at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #3 from Josh Haberman <jhaberman at gmail dot com> ---
> That being said there is a missed optimization but that is the same as PR
> 23384 .
> The const part is a misleading you really.
I think there are two issues here.
1. Escape analysis is not flow sensitive. I agree that aspect of my bug report
is a dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384, and closing as
a dup is appropriate there.
2. Escape analysis does not take 'const-ness' of the underlying object into
account.
Let me illustrate (2) with an example that isolates that issue (Godbolt:
https://godbolt.org/z/16cv87s9d)
void ExternFunc(const int*);
int Bad() {
const int i = 0;
const int* pi = &i;
ExternFunc(pi);
return *pi;
}
int Good() {
const int i = 0;
ExternFunc(&i);
return i;
}
These two functions are effectively the same, but in Bad() GCC does not perform
constant propagation across the external function call. While it's true that
the pointer escapes, the underlying object is const and cannot change, so
constant propagation should work here, as it does in Good().
Currently GCC re-loads `i` from the stack in Bad(), even though we know
statically that the value must be zero.
The same missed optimization is present in Clang:
https://github.com/llvm/llvm-project/issues/59694
