Re: RFC: allowing fwprop to propagate subregs

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> [Richard, combine question at the bottom for you.  I've quoted Ulrich's
>  whole message in order to provide a bit of context.]

I don't remember ALL of this, but can perhaps make a few hints.

> > The problem appears to be that an RTX expression like
> >
> >     (minus:QI (subreg:QI (reg:SI 64 [ a ]) 0)
> >               (subreg:QI (reg:SI 66 [ b ]) 0))
> >
> > seems to be considered non-canonical by combine, and is instead
> > transformed into
> >
> >     (subreg:QI (minus:SI (reg:SI 64 [ a ])
> >                          (reg:SI 66 [ b ])) 0)
> > On the one hand, this seems odd, as SUBREGs with a non-trivial
> > expression inside will usually not match any insn pattern.  On
> > the other hand, I guess this might still be useful behaviour
> > for combine on platforms that support only word arithmetic,
> > when the SUBREG might be considered a "split" point. 

No, I think the idea was that the outer SUBREG would be moved to the LHS
of the assignment to make a "paradoxical SUBREG".  Except, as you point
out, there doesn't seem to be an advantage of doing this for arithmetic
unless you only have it in SImode (which it could, of course, check).

> (Of course, this doesn't work for the compute-result-and-cc type patterns.)

Right.

> No immediate suggestions, sorry.  It looks like the combine case was
> added by this pre-egcs patch:
> 
> Wed Mar 18 05:54:25 1998  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
> 
> 	* combine.c (gen_binary): Don't make AND that does nothing.
> 	(simplify_comparison, case AND): Commute AND and SUBREG.
> 
> so maybe Richard remembers (or has a record of) what this was designed
> to handle?

I suspect the two halves related to each other: we commute AND and SUBREG
in the hope that this will allow us to decide that the AND does nothing
and isn't needed.  But I don't see how this is related: this is the AND
case in a comparison and we have a MINUS.