This is the mail archive of the 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: Question on calculating register pressure before ira pass

On 08/20/2012 05:00 AM, Bin.Cheng wrote:
Currently I am working on improving hoist pass by calculating register
pressure and using the info to guide hoist process. It works well and
I will send a patch once I finish it.
Sorry for the delay with the answer. Looking at the bigger picture, I believe (and I already expressed this opinion several times) that we need a general register pressure decreasing pass before 1st scheduler which should include rematerializations (e.g. see Simpson's aproach in his PhD.) and live-range shrinkage. Otherwise, we will have more and more complicated register-pressure aware optimizations (e.g. Bill Schmidt proposed this on last GNU Cauldron for his straight line strength reduction).

But this is only my wish. I don't know who (may be me) will implement this and when. So please do not consider this as as discourage for your work moreover when it is already done. Sometimes temporary solutions continue forever as the right big permanent solution is never implemented.
In this work I reused codes in loop-invariant and called
ira_set_pseudo_classes function to calculate register pressure. The
problem is that ira_set_pseudo_classes sets pseudo_classes_defined_p
to TRUE, which causes function find_costs_and_classes scans
instructions only once to find the best reg class to use for each

In my understanding, these part of codes is introduced for calculating
reg pressure in schedulor and loop-invariant. What I do not understand
is why we make IRA behave differently when register pressure is
calculated before IRA pass?

The reg class and costs caluclations are very expensive procedure (O (# insns * # average number alternatives in insns * # reg classes)). Therefore we just try to reuse some cost info calculated in scheduler and RTL loop-invariant opt. for IRA. Of course the code is changed in scheduler, loop invariant opts, and in other intermediate opts but I guess some changes do not affect considerably on choosing costs and classes in IRA.

If you found that reusing such approach results in bigger regression, we could use 2 passes in IRA in any case for some targets (for x86/x86-64 I believe it has no sense as I did some measuring long ago) or use 2 cost passes for -O3/-Ofast in anyway.

Generally speaking, sometimes 3rd pass of costs could give better cost and class results. The algorithm stabilizes when there are no changes in costs and classes (and in practice it needs at least 3 passes).
In the work of hoist, I found bigger regression in code size causes by
the changed behavior of IRA.

My questions are:
1. could somebody give some explanation on this.
I think I gave it.
2. Is it possible to calculate register pressure by reusing existing
code while do not change behavior of IRA?

Yes, it is possible.

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