CSE fold_rtx subreg patch

Jeffrey A Law law@cygnus.com
Tue Sep 8 00:59:00 GMT 1998


  In message <199807130724.DAA18235@jwlab.FEITH.COM>you write:
  > > I'm also a little worried about the < to <= changes, particularly for
  > > SUBREGS since they are not optimized as well as REGs in other passes
  > > and thus "cost more".  Presumably you added it because the cases you
  > > tried had equal cost.
  > 
  > Instead of changing fold_rtx so it propagates subregs, another
  > approach is to change cse_insn so that it doesn't propagate
  > subregs (the issue, after all, is to simply be consistent).
Yup.  It took a little while for that concept to sink in.  :-)  I
think we'll both agree that being consistent is the right thing to
do.


  > The enclosed patch is an alternative to the earlier fold_rtx
  > patch and also results in better code then the unpatched cse.c
  > when compiling:
  > 
  >   unsigned char c;
  > 
  >   int
  >   func(unsigned char a)
  >     {
  >     unsigned char b;
  >  
  >     b = a;
  >     c = b;
  > 
  >     return b;
  >     }
  > 
  > on the i386.
  > 
  > ChangeLog:
  > 
  > Mon Jul 13 02:51:26 EDT 1998  John Wehle  (john@feith.com)
  > 
  > 	* cse.c (cse_insn): Don't consider replacing src with a
  > 	subreg unless we're looking for a paradoxical subreg.
Have your tried this on anything other than the trivial example?  Any
noticable improvement/regression?  What about your original fold_rtx
patch?

Do you have a preference between them?

Basically I'm being a little cautious here.  I don't know which scheme
is better.  The issue of not optimizing SUBREGs as well as REGs may be
a non-issue in reality.  I just don't know.  So, I'd like a little more
info on what happens with real code :-)

jeff



More information about the Gcc-patches mailing list