[PATCH] Fold zero extensions into bit-wise ANDs
Segher Boessenkool
segher@chello.nl
Wed Apr 17 08:53:00 GMT 2002
> The mystery is that the "obvious" patch applying this transformation
> inside the compiler produces different code to making the equivalent
> change in the input source code.
>
> In the very original code (current CVS), we actually had an 8-bit and,
> that was zero extended to 64-bits. My patch should have turned this
> into a single 64-bit and, but instead the resulting code ends up as a
> 32-bit and followed by a sign extension to 64-bits.
Original code:
long long foo(unsigned char bar)
{
return bar & 0x24;
}
that is,
long long foo(unsigned char bar)
{
return (long long)((int)bar & (int)0x24);
}
So, we had a zero extension from 8 to 32 bit, then the AND, and then
a sign extension from 32 to 64 bit.
Roger's patch folds the zero extension into the AND, but leaves the
sign extension; that explains the cltd.
Now, if you write
long long foo(unsigned char bar)
{
return (long long)bar & 0x24;
}
that is,
long long foo(unsigned char bar)
{
return (long long)bar & (long long)0x24;
}
you have a zero extension from 8 to 64 bit, which explains the xorl.
To get GCC to do this, you need a sign-extend of a zero-extend to be
optimized to the equivalent zero-extend. It looks like it doesn't
know how to do that, yet.
Segher
More information about the Gcc-patches
mailing list