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