This is the mail archive of the
mailing list for the GCC project.
Re: CSE fold_rtx subreg patch
- To: john at feith dot com (John Wehle)
- Subject: Re: CSE fold_rtx subreg patch
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 08 Sep 1998 01:57:46 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
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
> 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;
> func(unsigned char a)
> unsigned char b;
> b = a;
> c = b;
> return b;
> on the i386.
> Mon Jul 13 02:51:26 EDT 1998 John Wehle (email@example.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
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 :-)