On 3/20/21 4:33 PM, Richard Henderson wrote:
On 3/20/21 11:52 AM, Paolo Bonzini wrote:
+int main(void)
+{
+ return read_y();
+}
I think this should be "read_y() == 1 ? 0 : 1".
As a testcase returning 0 on success, yes.
I can reproduce it with -flto -O2 but not without -flto, do you agree?
Agreed. Replicated with a random recent gcc 11 snapshot.
This is really annoying of lto. It's clear something needs to change though.
Perhaps we can obtain the same optimization by wrapping reads of the page
size in an inline __attribute__((const)) function. Richard, what do you think?
I'll give it a shot and see what happens.
What exact version of gcc are you guys using? Something from rawhide that I
can just install?
So far I have failed to compile with gcc master with --enable-lto. Lots of
missing symbols reported at link time. Therefore I've been unable to actually
test what I intended to test.
That said, I'm not hopeful that __attribute__((const)) will work. I have an
idea that early inlining will inline tiny function calls too soon, before the
attribute has a change to DTRT during CSE. At which point we're left with bare
variable references and we're exactly where we would be if we did nothing
special at all.
Another workaround may be to avoid compiling exec-vary.c with -flto. I'm not
sure that my meson fu is up to that. Paolo?
I have filed a gcc bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696
Hopefully someone can address that before gcc 11 gets released. At which point
we need do nothing in qemu. Aldy?
r~
