[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Question about IRA (setup_allocno_priorities)
From:       Vladimir Makarov <vmakarov () redhat ! com>
Date:       2010-01-28 19:30:43
Message-ID: 4B61E5E3.8040608 () redhat ! com
[Download RAW message or body]

Ian Bolton wrote:
> Hi again,
>
> Thanks for your answer to my other question.
>
> I just found a case, where an allocno wasn't getting a register,
> when I thought it should, since it was referenced 24 times.
> I looked in setup_allocno_priorities() to see how this was used
> to determine the priority and found this line:
>
> mult = floor_log2 (ALLOCNO_NREFS (a)) + 1;
>
> All other things being equal, this means something that is
> referenced 16 times will get the same priority as something
> referenced 31 times.  I just changed this line to remove the
> floor_log2 and got better results on my test case.
>
> I'm wondering what the origins of the floor_log2 are?  You
> scale everything based on max_priority and INT_MAX later,
> so I don't see the harm in using the nrefs as the multiplier
> in the first instance, and I actually think this would be
> more representative of the impact of an allocno not
> getting a register.
>
>   
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.
> NOTE: I am still using the Priority algorithm because that
> performs better than CB on our architecture at the moment.
>   
Ok.

[prev in list] [next in list] [prev in thread] [next in thread]