This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Strange optimization in GCC 4.7.2
- From: Konstantin Vladimirov <konstantin dot vladimirov at gmail dot com>
- To: David Given <dg at cowlark dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 23 Jul 2013 17:05:55 +0400
- Subject: Re: Strange optimization in GCC 4.7.2
- References: <CADn89gTyW9ds-ZdQ+Rpwvzb+tPFTV_0j60GJe5_GqHivVarxqg at mail dot gmail dot com> <51EE7DC6 dot 10002 at cowlark dot com>
Hi,
But this is awfully wrong. In the general case (value >> 2) & 0xff !=
(value >> 2) & 0x80
Take value to be 0x3ff for example. Then 0xff != 0x80 itself. This
leads to wrong result.
---
With best regards, Konstantin
On Tue, Jul 23, 2013 at 4:57 PM, David Given <dg@cowlark.com> wrote:
> Konstantin Vladimirov wrote:
> [...]
>> x = (y & ~(1 << 7)) | (((value >> 9) & 1) << 7);
> [...]
>> x = y & 4294967167 | (value >> 9) << 7 & 255; <--------- WAT?
>
>
> ((value >> 9) & 1) << 7
> == ((value >> 9) << 7) & (1 << 7)
> == ((value >> 9) << 7) & 0x80
> == ((value >> 9) << 7) & 0xff
>
> ...I think.
>
> That last step is probably being done because anding with 0xff is really
> cheap on x86 (you just pick the appropriate subreg --- al instead of
> eax, for example).
>
> --
> ââââ ïïïïïïïïïïïïïï âââââ http://www.cowlark.com âââââ
> â "USER'S MANUAL VERSION 1.0: The information presented in this
> â publication has been carefully for reliability." --- anonymous
> â computer hardware manual
>