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 :-(.
