A new gimple pass (LRS: live range shrinking) to reduce register pressure
Xinliang David Li
Mon Jan 5 18:36:00 GMT 2009
On Mon, Jan 5, 2009 at 9:15 AM, Jeff Law <email@example.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
> 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?
More information about the Gcc-patches