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: Gcc 3.1 performance regressions with respect to 2.95.3


Hi,

On Tue, 28 May 2002 law@redhat.com wrote:

>  In message <200204252212.SAA22194@makai.watson.ibm.com>, David Edelsohn
> writes:
>  > 	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 ;) ).


Ciao,
Michael.


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