This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about IRA (setup_allocno_priorities)
- From: Jeff Law <law at redhat dot com>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: Ian Bolton <bolton at IceraSemi dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 03 Feb 2010 13:23:53 -0700
- Subject: Re: Question about IRA (setup_allocno_priorities)
- References: <4D60B0700D1DB54A8C0C6E9BE69163700D2B04A5@EXCHANGEVS.IceraSemi.local> <4B58C238.9010607@redhat.com> <4D60B0700D1DB54A8C0C6E9BE69163700D41D8EF@EXCHANGEVS.IceraSemi.local> <4B61CF25.5000301@redhat.com> <4D60B0700D1DB54A8C0C6E9BE69163700D492327@EXCHANGEVS.IceraSemi.local> <4B61E5E3.8040608@redhat.com>
On 01/28/10 12:30, Vladimir Makarov wrote:
It is originated from the old register allocator. I don't think that
just nrefs will work well because it is already reflected in the
cost. IMHO, log2 (nrefs) is here for taking code size into account
which affects code locality and as a consequence its execution
performance. But this is just speculations. Only benchmarking a lot
of credible tests will show the truth because all widely used RA
algorithms are heuristic ones. I am sure that a lot of people
(including me about 7 years ago) checked log2 (nrefs) and nrefs and
other priority definitions.
I wouldn't be surprised if the sources have had that form for more than
a decade... The "why" is probably lost forever.
One possibility if nrefs is generally worse than log2 (nrefs) is to use
a hybrid scheme. For a small nrefs, use it directly for a large nrefs,
use log2 (nrefs).
I certainly agree that benchmarking would be absolutely necessary before
any such change would be made.
jeff