A different view of volatile

[Hank Dietz]

In article <4548 at ihlpf.ATT.COM>, nevin1 at ihlpf.ATT.COM (00704a-Liber) writes:
> In article <7996 at pur-ee.UUCP> hankd at pur-ee.UUCP (Hank Dietz) writes:
> >Why not make use of this SAFE, prior-art, compiler hint?  Currently, a C
> >compiler is correct iff it treats ALL non-register variables as volatile
> >(unless flow analysis can prove that the object address is never taken:
> >i.e., unless flow analysis can prove that it would have been safe to place
> >the variable in a register :-).
...
> If a compiler assumes that all variables are volatile unless otherwise
> stated (such as by a register declaration), then I do not think that it is
> possible to do *ANY* type of optimization involving those variables.
> Even simple peephole optimizations such as 'a=b;a=b' cannot be
> legally optimized out, and 'x=2*y' and 'x=y+y' can yield two different
> results.  What kind of optimization (or non-optimization code generation,
> for that matter) is legal and what is illegal??

Not correct:  converting "a=b;a=b" into "a=b" often can be KNOWN SAFE.  You
only have to use register when the compiler wouldn't otherwise have noticed.

Suppose that a is declared "int a;" and that ALL references to a can be
seen.  If the address of "a" is never taken, then all references to "a" can
be safely removed; likewise, if "&a" is taken, only references to "a" where
"&a" reaches cannot be removed.  I'm oversimplifying a bit, but the basic
point is that the analysis to determine this for most LOCAL NON-POINTER
variables is quite easy, hence "register" helps only a little for local
variables.  It would be a big help for externs, statics, and for function
interfaces because it is very expensive (at least) for the compiler to see
all references when some references might be in other compilation units
(other files).

Even if we want to keep volatile, which I agree is probably a good idea given
that X3J11 has assumed it's there, we should at least permit register and
volatile to be used in very similar fashion, because they are conceptually
very closely related.

						-hankd