llvm dev - Jul 2008 - [LLVMdev] volatiles (was comparison of correctness of llvm and gcc)

Hi Duncan-
> does this also check that writes are atomic: that they are performed in
> one processor operation?
Can you elaborate a bit?  I don't think volatile has any atomicity 
requirements.  Of course I can make a struct, an int128_t, or whatever 
volatile (on AVR even an int16_t is updated non-atomically!).

Lack of atomicity is one of many problems with using volatile as a basis 
for creating correct systems code...

Thanks,

John

Hi John,
> > does this also check that writes are atomic: that they are performed
in
> > one processor operation?
> 
> Can you elaborate a bit?  I don't think volatile has any atomicity 
> requirements.  Of course I can make a struct, an int128_t, or whatever 
> volatile (on AVR even an int16_t is updated non-atomically!).
that's not entirely true in practice: if I do a 32 bit volatile write
to a memory-mapped i/o location, then I'd be annoyed if that got turned
into four 8 bit volatile writes.  And the hardware might react funny as
well!  Also, because languages like C currently only have a concept of
a volatile write and no concept of an atomic write (as far as I know),
I suspect it is common practice to use a volatile write of a size that
the processor is known to be able to perform atomically, and expect it
to end up as that atomic write in the final assembler (eg: a write of
a double should not be turned into two i32 writes on x86-32).  So I think
it is reasonable to expect LLVM to generate atomic reads and writes for
variables marked volatile if that can be done in a straightforward way
on the platform.  So my question is: are you testing whether LLVM does
in fact do this?  I appreciate that the C standard does not require it
(AFAIK).
> Lack of atomicity is one of many problems with using volatile as a basis 
> for creating correct systems code...
The Ada language has a proper notion of atomic write, but the gcc internal
language does not (AFAIK), presumably due to the C-centric origins of gcc.
So Ada marks the write "volatile", and generates a compile-time error
if
the write cannot reasonably be atomic on the target machine.  For example,
it allows a double to be atomic (but not an i64) on x86-32.

Ciao,

Duncan.

Hi Duncan,

We currently check that every byte of a volatile is accessed the same 
number of times, and that this number doesn't change across optimization 
levels.

If LLVM wants to make stronger guarantees that's great, I suspect this is 
not hard to all to check.  Can you provide a list of types that should be 
atomic for the x86 target?  For example would we expect a struct of size 4 
to be atomically accessed?  How about pointers?  Bitfields?  Actually I 
think the interaction of volatile and bitfields is murky so maybe we don't 
want to go there.

Also, right now we don't check that the order in which volatiles are 
accessed is the same across all optimization levels.  Fixing this is on my 
list.  As long as we generate code with at most one volatile access 
between any given pair of sequence points (which we do) the compiler is 
not free to reorder.

John