------- Comment #10 from ebotcazou at gcc dot gnu dot org 2010-01-13 23:27 ------- > Otherwise, I would simply remove this comment.
Fine with me, it's indeed a little confusing. > I does hunk #3, because I am not sure if all combination results from > case2 would pass "recog_for_combine". If any case fail, gcc may try > other combination patterns, where I am afraid changed_i3_dest=1 may > cause problem. I haven't read the code after validate_replacement > label thoroughly. To be conservative, I use hunk#3 to guarantee that > if the combination result from case2 is not recognized, nothing has > been changed. gcc is free to go ahead and try other combination > patterns. This is conservative. If anyone confirms that the cases that > I concern of will never happen, I am happy to remove hunk#3. Can you > confirm? Yes, jumping to validate_replacement means that the other combinations are not tried. If the new pattern is not valid, the code will try to massage it and not try other combinations. And I think that, in practice, it won't actually do anything since the various subsequent tricks are incompatible with case2. > Index: combine.c > =================================================================== > --- combine.c (revision 155801) > +++ combine.c (working copy) > @@ -2663,10 +2663,17 @@ try_combine (rtx i3, rtx i2, rtx i1, int > i2dest = SET_DEST (temp); > i2dest_killed = dead_or_set_p (i2, i2dest); > > + /* Replace the source in I2 with our dest and make the resulting > + insn the new pattern for I3. Then skip to where we > + validate the pattern. Everything was set up above. */ "Replace the source in I2 with the new constant and..." > SUBST (SET_SRC (temp), > immed_double_const (olo, ohi, GET_MODE (SET_DEST (temp)))); > > newpat = PATTERN (i2); > + > + /* If the result of combination is recognized, the note of I3 needs > + * to be removed. */ > + changed_i3_dest = 1; No need to invoke the consequences, just state the cause: "The dest of I3 has been replaced with the dest of I2." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42691
