{PING] [PATCH] Sign extension elimination

H. J. Lu hjl@lucon.org
Thu Apr 20 17:09:00 GMT 2006

On Thu, Apr 20, 2006 at 09:39:23AM -0700, Mark Mitchell wrote:
> I'm not finding this discussion very illuminating.
> I'm trying to understand whether the current SEE pass is ready for
> inclusion in the compiler.  Roger has approved it on technical merits,
> but HJ has raised the issue that somehow this pass is a bad thing for
> x86-64.

The current SEE implemented isn't designed for x86-64 and doesn't help
x86-64 at all, if it doesn't make it worse on x86-64. But its
infrastructure is needed for future x86-64 SEE work.

> The fact that it doesn't presently help x86-64 doesn't worry me; the
> only question is whether it works in some way that is going to actively
> interfere with x86-64 support later.
> So, may we please have a discussion about whether or not this pass is
> inordinately PowerPC-specific?  I certainly didn't see anything in the
> discussion of the pass that suggests that; it looked like the same
> approach would probably work on other chips (ARM, MIPS) that have
> similar instructions.  Is that correct?

I think the current SEE implementation is very similar to


which tries to eliminate SE by improving SE placement. It is a
different problem we have on x86-64.

> What is it about the x86-64 instruction set that is so different from
> PowerPC in this regard?  Are any of our other x86 experts concerned
> about this pass?

What is so different for x86-64 is all 32bit register moves are
automatically zero extended to 64bit. That is

set ((reg:SI 10) (..defrhs..))


set ((reg:SI 10) (..defrhs..))
set ((reg:DI 10) (zero_extend:DI (reg:SI 10)))

But gcc generates

set ((reg:SI 10) (..defrhs..))
set ((reg:DI 100) (zero_extend:DI (reg:SI 10)))

instead of

set ((reg:SI 10) (..defrhs..))
set ((reg:DI 100) (reg:DI 10)))

When 2 registers are the same, we even get

set ((reg:SI 10) (..defrhs..))
set ((reg:DI 10) (zero_extend:DI (reg:SI 10)))

Those zero extensions aren't needed. This feature may be unqiue to


More information about the Gcc-patches mailing list