Re: DFA scheduler patch for review

[Jan Hubicka <jh at suse dot cz>]

> In message <322710000.1020184857@gandalf.codesourcery.com>, Mark Mitchell write
> s:
>  > > Anyway, I really don't expect the DFA scheduler to have the kind of
>  > > negative impact that the inliner had.
>  > 
>  > I agree.
>  > 
>  > The flip side of Jeff's point (that you only get the DFA scheduler where
>  > it's turned on) is that we now again have two schedulers.  It would be
>  > good if people would collaborate to do DFA schedulers for all the ports
>  > so that we can lose the old new scheduler.
> More correctly, we have two methods for describing a processor pipeline and
> two methods for the scheduler to query that information from the backend.

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.

On the branch I made EBB scheduler to update CFG and I will modify it soon to
update liveness as well.  Also with tracer I already implemented independently
I can turn it into trace scheduler easilly.

I plan to do some benchmarking next week, once the DFA will be merged into
the cfg branch so I will be able to do better benchmarking on the sparcs.
It would be nice to make one of the two scheduler obsolette the other.

Honza
> 
> For folks who are considering updating their ports; I would strongly recommend
> first converting to a DFA description which produces the same code as the old
> description.  That will give you familiarity with how to describe pipelines
> using the new scheme and you can verify that the description does what you
> expect by comparing the old and new schedules.  I've found this invaluable
> for the PA port.
> 
> Once you've got a solid DFA description, then move to trying to improve it
> by more accurately describing the various cpu units and reservations.
> jeff