volatile [was: GCC warnings for unused global variables]

[Mike Stump]

On Wednesday, May 7, 2003, at 04:13 PM, Richard Henderson wrote:
> On Wed, May 07, 2003 at 03:58:24PM -0700, Mike Stump wrote:
>> On Tuesday, May 6, 2003, at 09:03 PM, Alexandre Oliva wrote:
>>> But then, so is a single instruction that loads, operates then 
>>> stores,
>>> right?  The thing is that GCC doesn't ever give such instruction a
>>> chance if the variable is volatile.
>>
>> But, obviously, it should be made to.
>
> No, that's not obvious at all.
>
> It means that, the behaviour of the program is going to depend on
>
>   (1) Whether the source was written as "i++" or "i += 1" or "i = i + 
> 1".
>       I think this would be astonishing to most C programmers.

I must not have explained in enough detail what I meant if you thought 
I meant that.
I meant something that isn't astonishing.  I meant that if the compiler 
would generate:

	load r0,M
	addi r0,1
	store r0,M

and if the architecture has:

	inc M,1

(defined as load, inc by 1, then store) then the optimizer should be 
free to generate:

	inc M

if it wants to.  Not obligated, not mandated, and not dependent upon 
the input form in the source language.  This transformation, I claim, 
isn't astonishing.  I'd claim it is expected (see volatile_okgcc mail 
thread from a while ago).

>   (2) Whether the architecture supports load/op/store instructions at 
> all.
>       This reduces portability of driver code across architectures.
>       Given the difficulty of validating driver code in the first
>       place, this is surely a big lose.

Nope, don't mean this.

>   (3) Whether a particular revision of an architecture issues its
>       load/op/store bus cycles in the same manner.  IIRC, 68000 vs
>       68020 is an example of this sort of change.

If the appearance to the outside world is different enough, then 
obviously the other instructions do not match and cannot be used to 
replace the first set.  Whether this is, or is not the case is port 
specific.  I don't mean to imply that such issues don't exist.

>   (4) GCC has never in its history issued load/op/store operations
>       for volatiles, and changing it now may well break previously
>       written drivers.  This would, in effect, be an ABI change.

I'd be surprised if there were no chips in the set of machines that 
would not care about this issue.  Imagine a hypothetical machine for a 
second that supports load, store, and inc (as above).  On this one 
machine, I claim (by definition) that the transformation is ok.  
Externally, it would appear that the processor fetched the memory, then 
wrote to the memory, with the value written would happen to be one 
greater than the value loaded.

Are you asserting that on every single CPU that gcc supports that all 
of them have different enough behavior to the outside so as to enable 
the outside to care?  And I mean more than just being able to tell from 
timing, timing, we have to agree, can and will change from time to time 
and that while this can break drivers, it doesn't break well written 
drivers that we care to keep working.

Does x86 for example, how?