This is the mail archive of the gcc@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: IRA conflict graph & alternative selection


Jeff Law <law@redhat.com> writes:

> Ian Lance Taylor wrote:
>> Jeff Law <law@redhat.com> writes:
>>
>>   
>>>> No, that makes no sense.  What I'm suggesting is that we fix the stack
>>>> offsets of all local variables before register allocation, based on a
>>>> conservative assessment of how many registers will be saved on the
>>>> stack.  Then we know during register allocation whether the memory
>>>> reference will be in or out of the +- 16 byte range.       
>>> Just fixing the offset is not sufficient for the case I'm concerned
>>> about because you don't know what offsets are valid until you know
>>> precisely what registers are used in the insn.   That's absolutely
>>> critical.  So you have to assume worst case which is you can only use
>>> the +-16 byte insns which will pessimize just about every stack
>>> reference.
>>>     
>>
>> You fix the offset of the value stored on the stack.  Given that, you
>> know which instruction you can use.
>>   
> No, it's not that simple.  If you spill, then you can change the
> registers that are used and that in turn changes the set of valid
> offsets in reg+d instructions.

We are just talking in circles.  As I have been saying all along, I'm
suggesting that gcc conservatively determine which registers will be
used.  Then spilling will not change the stack space allocated for saved
registers.


>>> Perhaps the confusion in this case is because we're not really
>>> relaxing -- we're dealing with a case where the offset alone isn't
>>> enough to determine if the addressing mode is valid.
>>>     
>>
>> The confusion may be that we may be talking about different things.
>> I'm talking about removing this loop in the reload function:
>>
>>   /* This loop scans the entire function each go-round
>>      and repeats until one repetition spills no additional hard regs.  */
>>   
> Most of that loop's real work isn't in the address relaxation code,
> but in digging through instructions to determine what needs to be
> reloaded and how many registers are necessary to perform the requested
> reloads.

You are not using the word "relaxation" in the same sense that I meant
it.  I meant explicitly the process of finding the final set of
elimination offsets.


>> You know the size of the frame, by guessing conservatively as to how
>> many registers will be required.
>>   
> A conservative guess would be something like "every pseudo needs a
> slot" -- anything less than that isn't conservative, it's  optimistic.

Not a conservative guess at pseudo registers, a conservative guess at
hard registers.

I'm sorry, but I think I'm done with this thread.  I'm just repeating
myself, and people are critiquing things which I am not saying.

Ian


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