Re: [2.4] gcc3 warns about type-punned pointers ?

[Mikulas Patocka]

> > A collateral question: why is the reason for this function ?
> > long long assignments are not atomic in gcc ?
>
> Another question: why do we do _double_ store here?
>
> static inline void __set_64bit (unsigned long long * ptr,
>                 unsigned int low, unsigned int high)
> {
>         __asm__ __volatile__ (
>                 "\n1:\t"
>                 "movl (%0), %%eax\n\t"
>                 "movl 4(%0), %%edx\n\t"
>                 "lock cmpxchg8b (%0)\n\t"
>                 "jnz 1b"
>                 : /* no outputs */
>                 :       "D"(ptr),
>                         "b"(low),
>                         "c"(high)
>                 :       "ax","dx","memory");
> }
>
> This will execute expensive locked load-compare-store operation twice
> almost always (unless previous value was already equal
> to the value we are about to store)

It doesn't double store. cmpxchg8b does:
compare memory with edx:eax
	if equal, copy copy ecx:ebx into memory, set zf = 1
	else copy memory into edx:eax, set zf = 0

> AFAIK we can safely drop that loop (jnz instruction)

No. The only possible optimization would be to move 1: label directly at
cmpxgch8b. But it won't bring much, because loop is executed only if value
was changed after read and before cmpxchg.

There is another worse problem --- jump instructions are predicted as
taken when they point backwards, so it gets mispredicted. jnz should
really point to some other section, that is linked after .text, where
unconditional jump backwards would be.

Mikulas

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/