This is the mail archive of the gcc-patches@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: DFA scheduler patch for review


>  > Even more corectly, we even do have two schedulers.  We do have the region
>  > based global scheduler comming from Haifa and EBB scheduler sharing majority
>  > of code.
> Building of scheduling regions in the haifa scheduler should largely (if not
> completely) be the same problem as building EBBs.  In fact, if you refer back
> to the old documents from IBM Haifa, they're just building EBBS.
> 
> The implementation of building regions left a lot to be desired and has never
> worked as it was supposed to.  It's ripe for being ripped out and rewritten.
> 
> Can you describe in a little more detail what you've done?  It's likely we
> can use it to simply replace the lame code from Haifa.

I am basically refering to schedule-ebbs done by Bernd.  Unlike haifa it is
threading whole superblock (I am not sure where the EBB in name comes from) as
single basic block making the schedule better (I believe Haifa only moves
around the loads, so I get just very few intrablock moves from haifa).

All I've done is adding code to update CFG that has been the main stopper
preventing me to put schedule_ebbs as schedule_insns2 pass (that is local only
otherwise).

I would expect better results from trace scheduling than from the haifa, but I
really don't know yet.  Proper global scheduler would be definitly a win over
both approaches, but thats not what haifa is doing right now and it may be nice
if schedule-ebbs just obsoleted schedule-rgns as it is much easier and we may
add more sophisticated algorithm later.
> 
>  > On the branch I made EBB scheduler to update CFG and I will modify it soon
>  > to update liveness as well.
> Under what circumstances did you need to update the CFG?  The CFG should be
> unaffected by scheduling.  Liveness can change as instructions move between

When you do intrablock moves you may create new basic blocks (for instance by
moving partially dead code after the condtional jump and before following
label), kill basic block (by moving everything before preceeding conditional)
and you move the basic block boundaries.

Bernd's code didn't care this resulting in usuable CFG.

Honza
> blocks, but that's already handled.
> 
> jeff
> 


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