patch implementing a new pass for register-pressure relief through live range shrinkage

On 11/05/13 08:35, Vladimir Makarov wrote:
>    I'd like to add a new experimental optimization to the trunk.  This
> optimization was discussed on RA BOF of this summer GNU Cauldron.

[Good stuff snipped]

>
>    The single but significant drawback is additional compilation time
> (4%-6%) as the 1st insn scheduling pass is quite expensive.  So I'd
> recommend target maintainers to switch it on only for -Ofast.  If
> somebody finds that the optimization works on processors which uses
> 1st insn scheduling by default (in which I slightly doubt), we could
> improve the compilation time by reusing data for this optimization and
> the 1st insn scheduling.
Yow!  That's a pretty big hit.

Presumably there wasn't any way to integrate this with the existing 
sched2 pass, amoritizing the cost for dependency analysis and such?  Do 
we even know what part of the scheduler is really impacting compile-time 
performance here?






Jeff

On 11/05/2013 01:13 PM, Jeff Law wrote:
> On 11/05/13 08:35, Vladimir Makarov wrote:
>>    I'd like to add a new experimental optimization to the trunk.  This
>> optimization was discussed on RA BOF of this summer GNU Cauldron.
>
> [Good stuff snipped]
>
>>
>>    The single but significant drawback is additional compilation time
>> (4%-6%) as the 1st insn scheduling pass is quite expensive.  So I'd
>> recommend target maintainers to switch it on only for -Ofast.  If
>> somebody finds that the optimization works on processors which uses
>> 1st insn scheduling by default (in which I slightly doubt), we could
>> improve the compilation time by reusing data for this optimization and
>> the 1st insn scheduling.
> Yow!  That's a pretty big hit.
>
> Presumably there wasn't any way to integrate this with the existing
> sched2 pass, amoritizing the cost for dependency analysis and such? 
> Do we even know what part of the scheduler is really impacting
> compile-time performance here?
>
I guess you meant sched1 pass.  The 1st insn scheduler is more expensive
than the 2nd one, as we have less constraint dependency graph and
because we need to keep all insns in schedule-pressure mode whose source
insns were issued in one place to consider (not just ready ones). 
Practically most of code used for 1st insn scheduling is used and I
think there is no big opportunity to speedup the pass.  Although, for
example, we can use only BBs not just any scheduling regions (one
entry/several exits DAGs used by haifa-scheduler in regional mode), or
don't calculate insn priorities.

The biggest impact on 1st insn scheduling in register pressure sensitive
mode is to maintain and consider all insns from ready and queue in one
place.  Register-pressure sensitive scheduling is much more expensive
(as i remember from older experiments it may be in 2 times more
expensive than non-pressure sensitive one).

So some work could be done to speed up the code.  Still it will be
pretty expensive as the 1st insn scheduling pass in register-pressure
sensitive mode.
>
>
>
> Index: haifa-sched.c
> ===================================================================
> --- haifa-sched.c    (revision 204380)
> +++ haifa-sched.c    (working copy)
> @@ -150,6 +150,9 @@ along with GCC; see the file COPYING3.
>
>  #ifdef INSN_SCHEDULING
>
> +/* True if we do pressure relief pass.  */
> +bool sched_relief_p;
>
> Can we restructure things a bit so this is at least a file local
> static?  init/fini_for_live_range_shrinkage in haifa-sched.c, used by
> the bits in sched-rgn.c?
>
Sure. I'll modify the patch.