Gcc 3.1 performance regressions with respect to 2.95.3

Michael Matz matzmich@cs.tu-berlin.de
Tue May 28 09:32:00 GMT 2002


Hi,

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

> -- storing into a subreg like this can lead to poor code generation
> later -- especially if the pseudo does not get a hard register.

Yep, reload doesn't cope very well with subregs.

>  > This indeed has not the form of a REG_NOCONFLICT block, as insn 208 sets a
>  > completely different pseudo 185.  Attaching a REG_NOCONFLICT note for reg
>  > 182 to it would be wrong.  Double-hmm.  If only the scheduler would track
>  > the data flow correctly.
> Presumably you're talking about the subreg stores.

Actually about all insns involving subregs, defs and uses.  To precisely
track them would make REG_NO_CONFLICT unnecessary, ...

> Yes, it would be a huge benefit if flow/life and the schedulers
> properly tracked this stuff.  The single biggest reason we have naked
> clobbers is avoid -Wuninitialized warnings when dealing with

... as also such "misuses" of bare clobbers.  The new reg allocator does
this, but not in a general way to be able to reuse in flow/life (at least
I think so.  I haven't really thought about that.)


Ciao,
Michael.



More information about the Gcc-patches mailing list