Re: embedded target breakage [Was: Re: Patch commit requirements]

[Toshi Morita <tm2 at best dot com>]

Geoff Keating wrote:

> > > > http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01267.html
> > > 
> > > I still don't think this patch is right.  The docs for this function
> > > say:
> > > 
> > > /* See if X can be simplified knowing that we will only refer to it in
> > >    MODE and will only refer to those bits that are nonzero in MASK.
> > >    If other bits are being computed or if masking operations are done
> > >    that select a superset of the bits in MASK, they can sometimes be
> > >    ignored.
> > > 
> > >    Return a possibly simplified expression, but always convert X to
> > >    MODE.  If X is a CONST_INT, AND the CONST_INT with MASK.
> > > 
> > > There is no mention there that this will apply the MASK to the
> > > parameter _unless_ it is going to return a CONST_INT; your patch seems
> > > to generate an AND rtx always, which is certainly wrong around a
> > > CONST_INT because (and (const_int) (const_int)) is not valid RTL.
> > 
> > Alright; I can handle the CONST_INT case, but can you at least
> > verify that my analysis appears correct before I proceed further?
> 
> No, I didn't mean that I thought there was a specific problem with
> CONST_INT, I meant that I thought your analysis was wrong, because
> according to its documentation this routine shouldn't be creating the
> AND at all.

The caller of this routine strips off the and:SI around the rtx
and passes in the child rtx and the bitmask. 

If the and:SI operation cannot be propogated down into the child
RTXes, then somebody has to restore the original and:SI around
the rtx.

Either:

1) force_to_mode needs to manually restore the and:SI rtx
   (My last patch implments this), or

2) force_to_mode needs to return a flag which indicates the
   bitmask could not be propogated down into the child rtxes,
   and each caller of force_to_mode correctly check the return
   flag and handle this case (nasty - all callers of force_to_mode
   would require modification), or

3) force_to_mode is being called incorrectly in this case 
   (and several other cases) because it shouldn't be called
   with an arbitrary bitmask that is not an integral mode
   (My first patch, but everyone said simply disabling the
   call wasn't correct).

I can't think of any other possible interpretations of this 
situation.

Which one of these is correct, or am I missing something?

Toshi