This is the mail archive of the
mailing list for the GCC project.
Re: Improve unrolled size estimates
On Mon, 11 May 2009, Jan Hubicka wrote:
> > > I guess it ought to handle unknown constant too and claim that result is
> > > unknown constant, right? (it doesn't)
> > Yes, that's a missed optimization. We'd need to invent some tree
> > to return for 'unknown constant' though.
> OK, so I guess the overal plan would be
> 1) fix CCP so it can estimate that load from initialized constant array
> or string will be unknown constant if all indices are unknown constants
> 2) reorganize SSA propagator to work on specified blocks
> 3) add support for partially populating CCP lattices by "varying" for
> everything that is not IV variable and not defined inside the selected
> 4) add support for CCP to do only propagation and return list of
> statements that are constant now
> 5) reorganize the cost function to use result of it instead of my
> constant_after_peeling predicate
If you want to go the full way, yes.
I think fixing 1) shouldn't be too difficult, the rest is for going
full CCP propagator. With 1) fixed you'd need to only add 3) to be
able to use fold_const_aggregate_ref from your estimates. That would
be a reasonable intermediate step (I bet that if we put in your patch
now it will stay that way ... :/).
That is, I still dislike that you only handle constant index loads
from strings. How does the benchmark numbers look like if you
> I am affraid that I don't have time right now to do all that, there are
> still too many other things on my TODO list.
> I've dropped the patch into pretty-ipa. There are several improvemnts:
> SPECINT EON 2130->2465 (base only). GEOM is up 1433->1454
> EON has loop zeroing small vector in the internal loop. I guess it
> now gets fully unrolled. Size seems same.
> SPECFP base Wupwise 1485->1491, swim 1529->1540, applu 1250->1275,
> equake 1680->1775, facerec 1991->2030,
> (equake is important)
> SPECFP peak wupwise 1395->1417, applu 1326->1355, mesa 1472->1500
> art 2219->2248,
> There is also code size regression on botan
> and raytracer
> So I guess it is worthwhile to play with it. I would be however happy
> if someone beats me ;)))
Dissecting the patch would be nice. The formula adjustments look
pretty obvious, so do the last-iteration fixes...
Well. I will he happy to approve a version that uses