This is the mail archive of the
mailing list for the GCC project.
Re: Gcc 3.1 performance regressions with respect to 2.95.3
- From: Michael Matz <matzmich at cs dot tu-berlin dot de>
- To: <law at redhat dot com>
- Cc: David Edelsohn <dje at watson dot ibm dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 28 May 2002 17:46:57 +0200 (MET DST)
- Subject: Re: Gcc 3.1 performance regressions with respect to 2.95.3
On Tue, 28 May 2002 email@example.com wrote:
> In message <200204252212.SAA22194@makai.watson.ibm.com>, David Edelsohn
> > Sigh^2. The open-coded no-conflict block does not work as a
> > normal no-conflict block. This algorithm probably is not strictly a word
> > at a time, so no-conflict causes optimization errors down the line.
> Bummer. Are we still going to need the naked clobber though? Presumably we
> have it for flow's benefit?
It's needed at least when we are not using a new pseudo. If it weren't
there the different live ranges of that pseudo wouldn't be separated.
I.e. yes, I think for flow's benefit.
> > I guess one other question is why the target REG is re-used
> > instead of a new pseudo generated. That also would prevent the DEAD notes
> > from disappearing.
> If you can safely use a new pseudo that would be preferable; various early
> passes in the compiler try to be sensitive to the needs of 2 address
> architectures (x86, m68k, etc) and sometimes re-use pseudos. However, I
> think that's exposing target details far earlier than is advantageous. So
> I'm all for generating a new pseudo.
Dito. Although this then hides the current problem in the scheduler.
To have many pseudos currently even helps register allocation, as only the
new one can handle a pseudo consisting of multiple live ranges (well,
besides the debugging support for that ;) ).