A new gimple pass (LRS: live range shrinking) to reduce register pressure

[Xinliang David Li]

On Mon, Jan 5, 2009 at 9:15 AM, Jeff Law <law@redhat.com> wrote:
> Vladimir Makarov wrote:
>>
>> Steven Bosscher wrote:
>>>
>>> In my perfect GCC, we'd have a register pressure control mechanism on
>>> GIMPLE (not too smart, but just enough to avoid really stupid things)
>>> and live range shrinking on RTL, preferably as part of sched1.
>>>
>>>
>>>
>>
>> I am agree with Steven.  Although the LRS pass gives a nice improvement
>> (about 0.3%-0.5% for SPEC2006 on i686 according to my calculations from the
>> posted numbers.  I think the result would be less for targets with sched1
>> switched on or targets for bigger register file), the LRS pass as a single
>> solution probably is not fully adequate because it is too early.
>>
>> I tried analogous thing (Simpson's approach of register pressure relief
>> through remateriliazation) five years ago (it was reported on 2004 GCC
>> summit).  It was implemented on RTL and even on this stage it can not help
>> much because register pressure calculation was inaccurate mainly because
>> pseudos could have intersected register classes in the old RA.  IRA uses
>> non-intersected register classes for most targets and it opens possibilities
>> for more accurate register pressure relief passes (through rematerilization
>> or LRS).  I hope it is already helped this pass.
>>
>> By the way I am going to work on LRS in sched1 when I am less busy with
>> IRA.  I planned that long time ago.
>>
> While I can see the appeal of doing range-shrinking early in the pipeline
> (it's a relatively simple code motion algorithm), I have a hard time seeing
> how it's going to be very beneficial.   ISTM we want:
>
>  1. Something to prevent the optimizers from doing stupid and creating
> horribly inefficient code early.

Again this requires analysis work -- not simple heuristic based guess
work. In LRS, the most of the compile time is probably in the analysis
part already -- the transformation part is relatively cheap. If the
main concern is compile time and that it may not help other targets as
much, I can certainly use a flag to shut it down for most of the other
targets.


>
>  2. Live range shrinking via code motion only which runs after sched1.
>

Or as part of (a prepass) of IRA when interferences are computed.
Again, I do not see why LRS can not coexist with this future pass
where each one can have different focus (with the same objective).



>  3. Range Splitting and other pressure reduction techniques which may
> require copy insertions, spill to memory, etc.
>    These may be part of the allocation/spilling process itself or separate
> pre allocation passes.

Aren't these techniques there in IRA already including remat?

David
>
>
>
>