[llvm-commits] [llvm] r100459 - /llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp

[Duncan Sands]

Hi Dan,

> +  // FIXME: If the memcpy is volatile (isVol), lowering it to a plain libc
> +  // memcpy is not guaranteed to be safe. libc memcpys aren't required to
> +  // respect volatile, so they may do things like read or write memory
> +  // beyond the given memory regions. But fixing this isn't easy, and most
> +  // people don't care.

are volatile loads/stores really not allowed to read or write beyond the given
memory regions?  I don't know about C, but Ada has both "atomic" and
"volatile", where "atomic" means that exactly the given piece of memory is
read/written, and it must be done in a single (atomic) processor operation.
As far as I know "volatile" is the same as in C, and doesn't imply either of
these things.  That said, from a quality of implementation point of view it
would be good if volatile loads/stores in LLVM turn into atomic processor
operations whenever possible (I did some codegen work to ensure this in a
bunch of cases a year or two ago).  Also, some memcpy implementations do stuff
like: zero out the destination before doing the copy (this speeds things up on
some machines due to cache effects).  That means that the "volatile" copy
results in multiple stores to each of your I/O registers, once for the zero and
once for the actual copy.

Ciao,

Duncan.