You can work around the unsafe issue with a wrapper type that exposes a safe interface around volatile_{load, store}.
Regardless of what the compiler does, technically there is no guarantee that the malloc implementation itself doesn’t go around randomly reading contents of previously allocated buffers just to annoy you, so I suggest going as low level as possible and using mmap or platform equivalents. This has the advantage of letting you use mlock to prevent paging, if you want…
I suspect that whatever the C standard says, LLVM is never going to do any optimizations on volatile accesses in IR - indeed, it looks like GCC’s similar behavior is basically a bug. But if for some crazy reason it someday tries to, using mmap should also ensure it can’t do so in your case, because it wouldn’t be able to detect you’re not writing to a “real” volatile object - whatever that means outside of C-land.
However, Amanieu is completely right that the compiled code is likely to leave data lying around in registers and/or the stack; not to mention that there’s no guarantee the optimizer won’t change constant-time code to non-constant-time. Not sure if it’s still maintained, but have you seen nadeko?