This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Gcc 3.1 performance regressions with respect to 2.95.3
- From: law at redhat dot com
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Michael Matz <matzmich at cs dot tu-berlin dot de>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 25 Mar 2002 21:31:29 -0700
- Subject: Re: Gcc 3.1 performance regressions with respect to 2.95.3
- Reply-to: law at redhat dot com
In message <200203252318.SAA27178@makai.watson.ibm.com>, David Edelsohn
writes:
> >>>>> Jeff Law writes:
> The dependence code computes the correct dependence relationship,
Right. Without it the clobbers could move to a point after the use/set,
which would generate incorrect code.
> 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.
Err, the register pressure code from IBM Haifa was junk. I know because I
sat down and evaluated the later drops. It was total junk.
> The main affect on the scheduler moving the clobbers far away from
> the use/def sites is the issue rate.
So that's were we need to concentrate our focus.
When we schedule a clobber, we should not decrement can_issue_more for
the current cycle. Additionally, any instructions which have their final
dependency resolved due to issuance of the clobber should go into the
ready queue with a cost independent of the anti dependency relative to
the clobber. [ And priority computation should ignore clobbers. ]
I believe if you do those things your problem will be solved.
> IMHO, no-unit should not be counted against the issue rate and
> some other mechanism needs to keep those instructions from issuing early.
Possibly. Though that may have other undesirable effects depending on how
the machine description works. Instead I would make the special handling
dependent on PATTERN (insn) == CLOBBER.