volatile store/load

Clang Frontend
1

Hmm, I'm not completely sure... on the one hand, we are basically
guaranteed to have type information along with any LValue. On the
other hand, it affects how the load should be constructed, and should
therefore be associated with the LValue along with other properties
which can't be derived from the type, like alignment. I'm leaning
towards putting volatility into the LValue, but I could be convinced
that the other approach is superior.

-Eli

2

We've hit this sort of problem in spades in llvm-gcc. The "right" fix we converged on (but haven't yet implemented) is to add a volatile flag and alignment field to the LValue structure. IIRC, the 'volatility' of a load or store follows the destination being stored into (e.g. a bitfield, horrors!) not the expression being stored into it.

-Chris