This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange optimization in GCC 4.7.2


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
>>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]