------- Comment #5 from wilson at gcc dot gnu dot org  2006-06-10 02:49 -------
If a combination is successful, we will delete i1 and i2, so it doesn't matter
if they changed accidentally.

If a combination fails, then we go through undobuf and revert all changes, so
it doesn't matter if i1 or i2 changed accidentally.  They will be restored to
their original values when we are done.

The only case where it matters is if added_sets_2 or added_sets_1 is true.  In
this case, we will re-add the patterns from i1 and/or i2 after the combination.
 So in this case, we need to make sure we still have the original patterns.  We
already make a copy of the i2 pattern for this purpose.  i2pat is a copy, and
is only used if added_sets_2 is true.  So we just need to do the same for
i1pat.

I agree the comment before the i2pat is a bit confusing.  It looks like the
copy was originally added to fix an obscure problem, but it also happens to fix
this one too.

It looks like there is an unnecessary gen_rtx_SET call, as i2pat will only be
used if added_sets_2 is true.  So the code setting i2pat should be moved inside
the added_sets_2 if statement.  The new i1pat code should work the same way.

The actual modification of the if_then_else rtl happens inside force_to_mode,
as called from simplify_and_const_int.  See the uses of SUBST in the
if_then_else case in force_to_mode.  This problem could be fixed if we
generated new rtl here instead of using SUBST, but I don't think that is
helpful, as there are other places that also call SUBST.  It is safer to make
the i1pat copy.


-- 

wilson at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-10 02:49:49
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761

Reply via email to