[Bug tree-optimization/125672] Jump threading hurts conditional select formation

[rguenth at gcc dot gnu.org]

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?