https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125672
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Drea Pinski from comment #7) > (In reply to ktkachov from comment #6) > > Can we teach the threader in tree-ssa-threadbackward.cc profitable_path_p to > > reject paths that are likely to be if-converted i.e. it is a diamond with > > pure operations and no memory ops that ends in a 2-operand PHI of a mode > > that can_conditionally_move_p ? I have a prototype for that that fixes the > > benchmark in question and seems to be relatively clean testsuite-wise > > No because a lot of the time those are the ones which you want to be jump > threaded. > > E.g.: > If (a) c = 2; else c = 3; > If (c == 3) .... if it is really if (a) c = 2; else c = 3; if (b) d = 1; else d = 2; if (c == 3) then jump threading would duplicate the if (b) diamond. What we might want to do instead is "swap" the above to if (a) c = 2; else c = 3; if (c == 3) if (b) d = 1; else d = 2; before jump-threading. jump-threading has cost limits to limit the amount of copying already, so for large middle sub-CFGs we should already avoid it. IIRC the old forward threader also only supported a single middle-BB, not a diamond. Unsure about the backward threader. So what's the actual situation here?
