This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, IRA] Fix ALLOCNO_MODE in the case of paradoxical subreg.
- From: Vladimir Makarov <vmakarov at redhat dot com>
- To: Wei Mi <wmi at google dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, David Li <davidxl at google dot com>
- Date: Wed, 25 Sep 2013 13:19:02 -0400
- Subject: Re: [PATCH, IRA] Fix ALLOCNO_MODE in the case of paradoxical subreg.
- Authentication-results: sourceware.org; auth=none
- References: <CA+4CFy73kNt8naM0Ds_8q7cpCn77aTtVRgCHUBiSFacJMQ+L7g at mail dot gmail dot com> <524304C2 dot 1040304 at redhat dot com> <CA+4CFy7APRWjyjAecTQoo=S-+5f0G79Xa_My77eYQiJ1HBkr-g at mail dot gmail dot com>
On 09/25/2013 12:42 PM, Wei Mi wrote:
>> performance. For example, we have code
>> ... (reg:DI) ...
>> ... (subreg:TI (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