Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock

[Jeremy Fitzhardinge]

On 07/14/2010 11:19 AM, H. Peter Anvin wrote:
> On 07/14/2010 11:15 AM, Jeremy Fitzhardinge wrote:
>   
>> I think we should consider that deprecated and rely on dependencies and
>> clobbers.
>>
>>     
> I don't think that's practical in general.  If the compiler is *that
> broken*, I don't see how it is usable at all.
>   

Well, over the years, gcc has explicitly changed the docs to weaken the
meaning of "asm volatile" from "not being moved ``significantly''" to
"no real guarantees about movement at all".

I don't see why its so broken.  There are lots of mechanisms to control
asm ordering; we don't need "asm volatile" as well.  But we do need it
to mean "still emit an apparently dead asm with no outputs (or unused
outputs)".

They can still be omitted if the whole basic block is dead code, and
they can be duplicated by things like inlining and loop unrolling.  But
presumably they can never be evaluated more times than the source code
says they should be, so to that extent they're like volatile variables.

I think the use of the "volatile" keyword here is a red herring.  Just
because the gcc devs decided to use it as a qualifier for asm statements
doesn't mean that one should read anything other than a vague, vague
relationship to volatile variables (and extra-vague given how weakly
defined *they* are).

> As Linus indicated, I don't think we can assume the gcc documentation to
> accurately reflect the intent of the gcc team, mostly because I think it
> often lags way behind what they're thinking.
>   

I can get not trusting gcc to do what the documentation says it should
do, but relying on it to do things that the documentation definitely
says it doesn't seems foolhardy.

I'm finding it a bit surreal to be arguing on the side of "don't trust
gcc" vs you and Linus on the "gcc developers are arbitrary, capricious
and untrustworthy, but we can rely on this piece of undocumented
behaviour" side.

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