Re: Redundant logical operations left after early splitting

[Jeff Law <law at redhat dot com>]

Paolo Bonzini wrote:
> > > Is there any particular function or pass that should be dealing with 
> > > IOR rx,0 - that I could trace thru and figure out why it does not 
> > > like it (or never gets there)?
> > I would be looking in combine and simplify-rtx (which is called by
> > combine).  If your splitter triggers after combine, then I'm not
> > immediately sure where to look -- I'm not offhand aware of a pass
> > after combine which would call into simplify-rtx to perform this
> > optimization.
>
> Me neither, but this
>
>       if (flag_expensive_optimizations)
>         {
>           /* Pass pc_rtx so no substitutions are done, just
>              simplifications.  */
>           if (i1)
>             {
>               subst_low_luid = DF_INSN_LUID (i1);
>               i1src = subst (i1src, pc_rtx, pc_rtx, 0, 0);
>             }
>           else
>             {
>               subst_low_luid = DF_INSN_LUID (i2);
>               i2src = subst (i2src, pc_rtx, pc_rtx, 0, 0);
>             }
>         }
>
> could be a place where it is done.
I'm still looking at this, but I don't see much of a chance to attack
this specific problem in the combiner.

I'm thinking this is going to need to be attacked along one of three
lines:

  1. Having split_all_insns conditionally run a cleanup pass if
     it's likely to be profitable (constant propagation &
     rtl simplification)

  2. Make local smarter about propagating constants and find
     somewhere to simplify to eliminate the nops.  Final could
     do it much like it used to eliminate nop-moves and the like.

  3. Investigate emitting better code in the splitters.

Jeff