Strange optimization in GCC 4.7.2

Strange optimization in GCC 4.7.2

[Konstantin Vladimirov]

Hi,

Simple code:

void somehowuse(unsigned value);

void
foo( unsigned value,
unsigned bytemask,
unsigned psw,
unsigned y)
{
unsigned x;

psw = (psw & ~(1 << 10)) | (((value >> 9) & 1) << 10);

x = (y & ~(1 << 7)) | (((value >> 9) & 1) << 7);

somehowuse(x);
somehowuse(psw);
}

Compile to assembler with gcc-4.7.2:

$ gcc -O1 -fomit-frame-pointer -S test.c -fdump-tree-all-lineno-details

Look at test.c.003t.original

unsigned int x;
psw = psw & 4294966271 | (value >> 9 & 1) << 10;
x = y & 4294967167 | (value >> 9) << 7 & 255; <--------- WAT?
somehowuse (x);
somehowuse (psw);
}

I can not understand origins of 255 bitmask here. Maybe someone can
explain? Why psw is ok and x is so spoiled?

---
With best regards, Konstantin

Re: Strange optimization in GCC 4.7.2

[David Given]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: Strange optimization in GCC 4.7.2

[Konstantin Vladimirov]

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
>

Re: Strange optimization in GCC 4.7.2

[Konstantin Vladimirov]

Hi,

Disregard my previous message, I got your idea =) When we are shifting
right then left, then all bits except 7th will be 0 and andmask may be
any, while it contains 0x80. Yes everything is ok here, thanks

---
With best regards, Konstantin

On Tue, Jul 23, 2013 at 5:05 PM, Konstantin Vladimirov
<konstantin.vladimirov@gmail.com> wrote:
> 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
>>