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: [PATCH, IRA] Fix ALLOCNO_MODE in the case of paradoxical subreg.

On 09/25/2013 12:42 PM, Wei Mi wrote:
>> performance. For example, we have code
>> ... (reg:DI) ...
>> ...
>> ... (subreg:TI (reg:DI))
>> ...
>> ...(reg:DI)
>> We need two hard regs only for the second place by transforming
>> p = (reg:DI)
>> ...(subreg:TI p)
>> With this patch we requires two hard regs for the all live range of the
>> original pseudo (which can be quite long).  It might considerably worsen
>> code performance.
>> So the problem could be fixed in LRA which can make this transformation
>> or even in IRA (that would be even better as we put pseudo P into the
>> global picture vs. probably spilling some pseudos for P in LRA).
> Thanks for your detailed explanation. Now I understand what you concern here.
>> I need some time to think what is better (e.g. I don't know how to
>> implement it in IRA without big compilation slow down).  In any case,
>> the solution for the problem will be not that easy as in the patch.
> To fix it in IRA, it looks like we want a live range splitting pass
> for pseudos used in paradoxical subreg here. Is the potential
> compilation slow down you mention here caused by more allocnos
> introduced by the live range splitting, or something else?
 To define for what occurrence of the pseudo we should do the
transformation, we need to create allocnos and calculate reg classes to
know what paradoxical subreg needs more hard regs (the transformations
can not be done for all paradoxical subregs as my experience shows many
RTL changes result in worse RA even if we have heuristics to remove the
generated changes as in this case would be trying to assign the same
hard reg for the original and the new pseudo).
  After doing the transformations, we need to recalculate reg classes
and rebuild allocnos (both are expensive).  To speed up the process it
could be implemented as some kind of update of already existing data but
it will complicate code much.

So right now I think implementing this in LRA would be easier  Still LRA
has a pretty good register (re-)allocation (although it is worse than in

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