Volatile and sensitive memory

For anyone reading this thread as a reference for volatile: this no longer reflects our current understanding of how volatile and dereferencable interact. See this Github thread for the latest discussion, and in particular this quote by @hanna-kruppe:

If an lvalue is accessed through only volatile loads, LLVM will not add accesses that aren't volatile.

I've not seen this guarantee stated anywhere in LLVM docs. It seems reasonable on its own but the dereferencable attribute may very well throw a wrench in it. Without that attribute, LLVM may not assume it can insert loads from a pointer, so it won't insert any unless it sees a pre-existing load, which can be extended (with a bit of care) to take the volatile-ness of the existing loads into account and not take pre-existing volatile loads as permission to insert new loads. On the other hand, by definition dereferencable means it's OK to insert any loads from the address anywhere.

While one may be tempted to say "OK but don't do that if there are volatile accesses", that's not really possible. The transformation that wants to insert a load may not be able to see the volatile accesses (e.g., because they are in another function), or there may not even be any accesses at all to the location (e.g., if the source program creates a &VolatileCell but doesn't use it).

So, the current thinking is that you should not have references pointing to MMIO memory as the compiler is allowed to introduce spurious reads. But if you just want to zero-out memory and make sure the writes really happen, this should not affect you. (Please don't reply here but continue in the other thread).

4 Likes