https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 27 Jan 2020, amonakov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444 > > --- Comment #5 from Alexander Monakov <amonakov at gcc dot gnu.org> --- > The problem is lifting a conditional access. We don't have an example where > lifting an invariant from an always-executed block in a loop to its preheader > poses a problem. > > LLVM adopted an approach where hoisting must "freeze" the "poisoned" values > resulting from uninitialized access so they acquire a concrete unpredictable > value: https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf Interesting. GCC definitely has "undef", we at least do not explicitely have "poison" (I'm not fully understanding the difference). GCC also doesn't really formally define the effect of "undef" operands on any IL construct (well, or formally define the IL at all ...). But yeah, if you introduce "freeze" you basically add a proper definition for something formerly undefined with the semantic obtaining a stable value. Not sure if that's really desirable though. The paper also doesn't go into any detail on undefs that are "merely" not proven to be not defined. If you take for example static void foo (int i, int j) { if (i == j) return i; return j; } int main(int argc) { int undef; return foo(argc, undef); } if you transform foo to a plain return j; which GCC would do you only figure after inlining the function that j is actually undefined. Probably the example is bad.
