This is the mail archive of the gcc@gcc.gnu.org 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: Scheduler and GCC CFG


> >>>>> Jan Hubicka writes:
> 
> Jan> CFG based EBB scheduler is present on cfg branch.  It is simply run
> Jan> instead of current region based scheduler.  It is not completely
> Jan> finished but basically working (ie for instance it rebulds complete
> Jan> liveness info afterwards that can be done in smarter ways).
> 
> 	Thanks for the clarification that EBB and superblock scheduler are
> the same.
> 
> 	What exactly do you mean by a CFG-based EBB scheduler?  The
> cfg-branch has an option to run the EBB scheduler instead of the region
> scheduler for the second scheduler pass.  It fixes up the CFG after
> scheduling each block, but I do not see it using the CFG for scheduling
> any more than sched-ebb on the trunk.  There is no change to the scheduler
To my understanding the superblock scheduling algorithm as discussed in
literature consists of three main tricks - one is formation of traces
(superblocks) to schedule, other is scheduling the superblock as it if
were single basic block with few extra dependencies on jump boundaries
and last is insertion of compensation code to allow fewer dependencies
in the scheduling stage.

The first part is implemented by the tracer pass.  It is currently
merged into the trunk and run before 2nd cse pass to enable more
optimizations but the superblocks should remain conssitent until sched2
(or we can simply rerun it) as long as crossjumping is disabled.

EBB scheduler on trunk does basically the second step, so all I needed
is to allow it to integrate into normal compilation process (ie preserve
CFG) and slightly modify the superblock algorithm.

I didn't get into the compensation code.  As it is it already should be
enouth to test whether superblock scheduling can bring us something over
region based scheduler we have right now.  I tried that on Athlon and
the results are mostly random.  This is partly due to exact CPU model
(that has improved by DFA now), abd the fact that Athlon is not very
sensitive to scheduling.

I planned to play with this on some classic in-order machine but never
got into that since then.

Honza
> analysis and dependence calculation infrastructure.
> 
> Thanks, David


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