This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
> blocks
> 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
remove that?

> 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
> http://gcc.opensuse.org/c++bench-frescobaldi-ipa-64/botan/
> and raytracer
> http://gcc.opensuse.org/c++bench-frescobaldi-ipa-64/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 
fold_constant_aggregate_ref ...

Thanks,
Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]