Redundant logical operations left after early splitting

[Jeff Law]

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