[Bug rtl-optimization/69570] [6 Regression] if-conversion bug on i?86

[jgreenhalgh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570

--- Comment #2 from James Greenhalgh <jgreenhalgh at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> I guess ifcvt only triggers some latent bug, either RA or more likely in
> reg-stack.  That said, all the comments about the r229822 changes say its
> purpose is to handle multiple sets in the conditional block, but clearly the
> patch as implemented considers one set to be also multiple sets.  The
> problem with that is that it handles it worse than the code later on in
> ifcvt - it uses temporaries and hopes later passes get rid of those
> temporaries, but they actually affect the register allocation.
> By restricting the ifcvt multiple sets coversion to actually multiple sets
> like:
> --- gcc/ifcvt.c.jj	2016-01-21 17:53:32.000000000 +0100
> +++ gcc/ifcvt.c	2016-01-31 13:47:34.171323086 +0100
> @@ -3295,7 +3295,7 @@ bb_ok_for_noce_convert_multiple_sets (ba
>    if (count > limit)
>      return false;
>  
> -  return count > 0;
> +  return count > 1;
>  }
>  
>  /* Given a simple IF-THEN-JOIN or IF-THEN-ELSE-JOIN block, attempt to
> convert
> the test passes again, after ifcvt there are no additional unneeded
> temporaries and e.g. postreload dump contains 5 fewer instruction, and has
> fewer spills/fills.  Of course we really need to figure out what the bug
> actually is, but unless there is some strong reason (which should be
> documented), IMHO the above patch is right too.

Yes, that patch makes sense to me. If other ifcvt paths are doing a better job
of handling a single register move than the multiple-set code, then we should
use them.