https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110516
--- Comment #8 from Witold Baryluk <witold.baryluk+gcc at gmail dot com> ---
I see.
Point 1 is definitively incorrect. I interpreted asembler wrong:
void example.actualRun(ubyte*):
push rbp
mov rbp, rsp
mov QWORD PTR [rbp-8], rdi
nop
pop rbp
ret
The move there, is just some stack manipulation, it has nothing to do with
volatileLoad.
You are right about the side effect visibility and volatileStore.
Still, there should be a way to express real memory read, with result not
stored anywhere in program (just written to register, then discarded).
This has some (not very common) uses in memmory-mapped IO, i.e. in drivers for
devices where the read itself could indicate something (this of course usually
also require setting proper page table attributes to disable caching or other
optimizations, etc, not just volatile load in machine code). I do not have
specific examples at hand, but afaik I saw some examples in the past (mostly on
older architectures), as well some watchdog chips that reset timer on read.
Another use is for doing memory and cache read benchmarks and profiling. We
want to invoke read (to register) from some memory location, but we do not need
the value for anything else.
And more esoteric use might be memory probing. On some level systems, kernel or
bootloader, might not know the memory layout, and resort to just doing reads,
and relaying on CPU fault handlers to report invalid reads.
And some people might use load without destination, as a prefetch hint, or to
prefault some memory pages.
