https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
Aldy Hernandez <aldyh at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at gcc dot gnu.org --- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Jeffrey A. Law from comment #5) > It really depends on the growth necessary to expose the thread. I haven't > tried to evaluate that -- clearly if the code growth is unacceptable then > threading is the wrong answer. > > In general we should start each investigation of this kind of bug with an > analysis of what the threader has missed and the pros/cons of addressing the > missed thread. FWIW, with the newer backwards threader work we thread two different paths of 5 and 7 insns each. This sets up the CFG in such a way that DOM3 and VRP2 can continue massaging the input such that by the time we get to the uninit pass, "dst" is known to have a value of either f() or 0, and no warning is produced: dst_23 = f (); ... ... # dst_2 = PHI <0(5), dst_23(14), dst_23(16), dst_23(11), dst_23(18)> return dst_2; I don't see a substantial increase in block duplication. The new threader yields 11 blocks vs the old threader with 10 (and a spurious warning :)). But alas, this work won't land in GCC 8 :-(.