[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