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.
