Re: [Xen-devel] [PATCH] x86: fix variable_test_bit() asmconstraints

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 14.03.08 12:55 >>>
>On 14/3/08 11:23, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> I just sent a (much bigger, see below) patch to the same effect to the
>> x86 Linux maintainers - in Xen, all the operations modifying bits do
>> have "memory" clobbers, so it's just the test_bit() constraint that's
>> wrong.
>
>Yes, I agree that fix is needed, although it would be consistent with other
>asm statements in that file to use a memory clobbers instead.

But memory clobber aren't nice when you want the compiler to optimize
well.

>> However, I wonder whether the non-atomic ops aren't limiting things too
>> much by having "memory" clobbers, they would much better be restricted
>> to indicate just the changing memory location. This, however, would
>> probably require some additional consideration given that Xen (other
>> than Linux) isn't using -fno-strict-aliasing. Furthermore, these
>> non-atomic operations, according to their comments, can be re-ordered,
>> which contradicts the use of __asm__ __volatile__ (but note that
>> removing this would probably require extra precautions to meet strict
>> aliasing rules).
>
>Xen *does* use -fno-strict-aliasing. I'm afraid I don't understand why

Oh, okay, I just grepped xen/ for it, but it lives in Config.mk...

>memory-clobber would be needed for the atomic ops, but a dummy memory
>operand would suffice for non-atomic ops. I used memory clobber everywhere

Atomic ops imply a barrier (otherwise the compiler can defeat the
purpose of the atomic operation). The non-atomic ones don't need a
dummy operand, but one that precisely describes the place in memory
that changes.

>because at least I'm certain that works. Same for 'asm volatile'. We've had
>various problems with the bitops before, and I just want the darn things to
>work!

Okay, if you feel that way then I guess I won't propose changing it,
at the expense of slightly worse code generation.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel