Re: Gcc 3.1 performance regressions with respect to 2.95.3

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Jeff Law writes:

Jeff> Ignore libcalls for a minute and investigate why the scheduler decided to
Jeff> move the clobbers away from the use/def sites.   Something in the scheduler
Jeff> decided this was a profitable thing to do, when in fact it is a very 
Jeff> unprofitable
Jeff> thing to do.  If you can find out why, then you have a handle on how to deal
Jeff> with the performance issue.

	The dependence code computes the correct dependence relationship,
but all of the register pressure code in the final version of the Haifa
Scheduler deliverable from IBM is not present in the FSF tree.

	The main affect on the scheduler moving the clobbers far away from
the use/def sites is the issue rate.  The bare clobbers are scheduled on
unit -1 (no-unit).  However, the scheduler is treating unit -1 as a real
unit when applying the issue rate.  If the scheduler has enough other
work, it schedules the other defined units (e.g. integer unit and
load/store unit) before no-unit.  If there is no instructions ready to be
dispatched to the other units, it finds another unit with which to use up
its spare issue slots: "no-unit".

	For a wide-issue processor, there still may be issue slots
available even if the IU and LSU issue as well, therefore, the scheduler
grabs the clobber early.  For narrower issue processors, the other units
provide the back pressure on the clobbers until the other units are idle
because of clobber dependencies.  Then the clobbers issue on no-unit and
the real instructions issue in the next cycle.  After reload, there are no
pseudo-instructions scheduled to no-unit.

	IMHO, no-unit should not be counted against the issue rate and
some other mechanism needs to keep those instructions from issuing early. 

David