Should it be reported as a bug? (-O2 and cmpxchg instruction)

Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Martin Sustrik]

Hi all,

I've encountered a problem with gcc inline assembly.

Following code, when optimised with -O2 gives following machine code:

            __asm__ volatile (
                "lock; cmpxchgl %1, %3\n\t"
                "jz 1f\n\t"
                "mov %2, %%eax\n\t"
                "lock; xchgl %%eax, %3\n\t"
                "1:\n\t"
                : "=a" (oldval)
                : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
                : "memory", "cc");

 4031a0:   31 c0                   xor    %eax,%eax
  4031a2:   f0 0f b1 55 40          lock cmpxchg %edx,0x40(%rbp)
  4031a7:   74 06                   je     4031af
  4031a9:   89 c0                   mov    %eax,%eax
  4031ab:   f0 87 45 40             lock xchg %eax,0x40(%rbp)

Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This 
shouldn't happen given that cmpxchg modifies the value of %%eax.

Any idea whether this should be considered a bug and reported as such?

GCC version info:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v 
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release 
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Martin

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Andrew Haley]

Martin Sustrik wrote:
> Hi all,
> 
> I've encountered a problem with gcc inline assembly.
> 
> Following code, when optimised with -O2 gives following machine code:
> 
>            __asm__ volatile (
>                "lock; cmpxchgl %1, %3\n\t"
>                "jz 1f\n\t"
>                "mov %2, %%eax\n\t"
>                "lock; xchgl %%eax, %3\n\t"
>                "1:\n\t"
>                : "=a" (oldval)
>                : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
>                : "memory", "cc");
> 
> 4031a0:   31 c0                   xor    %eax,%eax
>  4031a2:   f0 0f b1 55 40          lock cmpxchg %edx,0x40(%rbp)
>  4031a7:   74 06                   je     4031af
>  4031a9:   89 c0                   mov    %eax,%eax
>  4031ab:   f0 87 45 40             lock xchg %eax,0x40(%rbp)
> 
> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This 
> shouldn't happen given that cmpxchg modifies the value of %%eax.
> 
> Any idea whether this should be considered a bug and reported as such?

Look for "earlyclobber" in the section Constraint Modifier Characters

Andrew.

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Martin Sustrik]

Andrew,

Thanks for prompt response. However, I am not sure how to use the 
earlyclobber modifier - this is actually the first gcc inline asembly 
code I've ever written.

Do you mean that I should add '&' sign to every operand in input operand 
list, or should I add the sign when using the operands or what?

The problem, AFAICS, is that cmpxchg modifies eax although eax is not an 
explicit operand of the instruction. Therefore optimiser has no idea 
that it is modified and acts as if it was unchanged :(

Martin

Andrew Haley wrote:
> Martin Sustrik wrote:
>> Hi all,
>>
>> I've encountered a problem with gcc inline assembly.
>>
>> Following code, when optimised with -O2 gives following machine code:
>>
>>            __asm__ volatile (
>>                "lock; cmpxchgl %1, %3\n\t"
>>                "jz 1f\n\t"
>>                "mov %2, %%eax\n\t"
>>                "lock; xchgl %%eax, %3\n\t"
>>                "1:\n\t"
>>                : "=a" (oldval)
>>                : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
>>                : "memory", "cc");
>>
>> 4031a0:   31 c0                   xor    %eax,%eax
>>  4031a2:   f0 0f b1 55 40          lock cmpxchg %edx,0x40(%rbp)
>>  4031a7:   74 06                   je     4031af
>>  4031a9:   89 c0                   mov    %eax,%eax
>>  4031ab:   f0 87 45 40             lock xchg %eax,0x40(%rbp)
>>
>> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This 
>> shouldn't happen given that cmpxchg modifies the value of %%eax.
>>
>> Any idea whether this should be considered a bug and reported as such?
>
> Look for "earlyclobber" in the section Constraint Modifier Characters
>
> Andrew.

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Andrew Haley]

Please don't top-post.

Martin Sustrik wrote:
> Andrew,
> 
> Thanks for prompt response. However, I am not sure how to use the 
> earlyclobber modifier - this is actually the first gcc inline asembly 
> code I've ever written.
> 
> Do you mean that I should add '&' sign to every operand in input operand 
> list, or should I add the sign when using the operands or what?

Use "=&a" on the first operand.

> 
> The problem, AFAICS, is that cmpxchg modifies eax although eax is not an 
> explicit operand of the instruction. Therefore optimiser has no idea 
> that it is modified and acts as if it was unchanged :(
> 
> Martin
> 
> Andrew Haley wrote:
>> Martin Sustrik wrote:
>>> Hi all,
>>>
>>> I've encountered a problem with gcc inline assembly.
>>>
>>> Following code, when optimised with -O2 gives following machine code:
>>>
>>>            __asm__ volatile (
>>>                "lock; cmpxchgl %1, %3\n\t"
>>>                "jz 1f\n\t"
>>>                "mov %2, %%eax\n\t"
>>>                "lock; xchgl %%eax, %3\n\t"
>>>                "1:\n\t"
>>>                : "=a" (oldval)
>>>                : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
>>>                : "memory", "cc");
>>>
>>> 4031a0:   31 c0                   xor    %eax,%eax
>>>  4031a2:   f0 0f b1 55 40          lock cmpxchg %edx,0x40(%rbp)
>>>  4031a7:   74 06                   je     4031af
>>>  4031a9:   89 c0                   mov    %eax,%eax
>>>  4031ab:   f0 87 45 40             lock xchg %eax,0x40(%rbp)
>>>
>>> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This 
>>> shouldn't happen given that cmpxchg modifies the value of %%eax.
>>>
>>> Any idea whether this should be considered a bug and reported as such?
>>
>> Look for "earlyclobber" in the section Constraint Modifier Characters
>>
>> Andrew.
> 

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Martin Sustrik]

Andrew Haley wrote:
> Please don't top-post.
>
> Martin Sustrik wrote:
>> Andrew,
>>
>> Thanks for prompt response. However, I am not sure how to use the 
>> earlyclobber modifier - this is actually the first gcc inline asembly 
>> code I've ever written.
>>
>> Do you mean that I should add '&' sign to every operand in input 
>> operand list, or should I add the sign when using the operands or what?
>
> Use "=&a" on the first operand.
Ok, I've modified the code this way:

            __asm__ volatile (
                "lock; cmpxchgl %1, %3\n\t"
                "jz 1f\n\t"
                "mov %2, %%eax\n\t"
                "lock; xchgl %%eax, %3\n\t"
                "1:\n\t"
                : "=&a" (oldval)
                : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
                : "memory", "cc");

However, the generated code is exactly the same as before.
>
>>
>> The problem, AFAICS, is that cmpxchg modifies eax although eax is not 
>> an explicit operand of the instruction. Therefore optimiser has no 
>> idea that it is modified and acts as if it was unchanged :(
>>
>> Martin
>>
>> Andrew Haley wrote:
>>> Martin Sustrik wrote:
>>>> Hi all,
>>>>
>>>> I've encountered a problem with gcc inline assembly.
>>>>
>>>> Following code, when optimised with -O2 gives following machine code:
>>>>
>>>>            __asm__ volatile (
>>>>                "lock; cmpxchgl %1, %3\n\t"
>>>>                "jz 1f\n\t"
>>>>                "mov %2, %%eax\n\t"
>>>>                "lock; xchgl %%eax, %3\n\t"
>>>>                "1:\n\t"
>>>>                : "=a" (oldval)
>>>>                : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
>>>>                : "memory", "cc");
>>>>
>>>> 4031a0:   31 c0                   xor    %eax,%eax
>>>>  4031a2:   f0 0f b1 55 40          lock cmpxchg %edx,0x40(%rbp)
>>>>  4031a7:   74 06                   je     4031af
>>>>  4031a9:   89 c0                   mov    %eax,%eax
>>>>  4031ab:   f0 87 45 40             lock xchg %eax,0x40(%rbp)
>>>>
>>>> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This 
>>>> shouldn't happen given that cmpxchg modifies the value of %%eax.
>>>>
>>>> Any idea whether this should be considered a bug and reported as such?
>>>
>>> Look for "earlyclobber" in the section Constraint Modifier Characters
>>>
>>> Andrew.
>>
>

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Andrew Haley]

Martin Sustrik wrote:
> Andrew Haley wrote:
>> Please don't top-post.
>>
>> Martin Sustrik wrote:
>>> Andrew,
>>>
>>> Thanks for prompt response. However, I am not sure how to use the 
>>> earlyclobber modifier - this is actually the first gcc inline asembly 
>>> code I've ever written.
>>>
>>> Do you mean that I should add '&' sign to every operand in input 
>>> operand list, or should I add the sign when using the operands or what?
>>
>> Use "=&a" on the first operand.
> Ok, I've modified the code this way:
> 
>            __asm__ volatile (
>                "lock; cmpxchgl %1, %3\n\t"
>                "jz 1f\n\t"
>                "mov %2, %%eax\n\t"
>                "lock; xchgl %%eax, %3\n\t"
>                "1:\n\t"
>                : "=&a" (oldval)
>                : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)

Ah, maybe I told you wrong: I see that Opernad 0 is also an input.  Sorry.

>                : "memory", "cc");
> 
> However, the generated code is exactly the same as before.

I certainly don't get that.  Please post a complete test case, with
assembly output.  We also need to know exactly your version of gcc.

Andrew.

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Martin Sustrik]

>
> I certainly don't get that.  Please post a complete test case, with
> assembly output.  We also need to know exactly your version of gcc.
>
Sorry, I am not able to make a simple test case as I don't know how to 
force gcc to inline the function that gets inlined in our product. 
Without the inlining everything looks to compile without problems. Is 
there any way to force inline?

Martin

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Andrew Haley]

Martin Sustrik wrote:
> 
>>
>> I certainly don't get that.  Please post a complete test case, with
>> assembly output.  We also need to know exactly your version of gcc.
>>
> Sorry, I am not able to make a simple test case as I don't know how to 
> force gcc to inline the function that gets inlined in our product. 
> Without the inlining everything looks to compile without problems. Is 
> there any way to force inline?

Declare it inline and compile with -O ought to do it.  GCC does not inline
any functions when not optimizing unless you specify the `always_inline'
attribute.

Andrew.

Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)

[Martin Sustrik]

Andrew,

Looks like earlyclobber solves the problem. I must have miscompiled the 
thing before when testing it.

Thanks for your help!
Martin