[PATCH] D27133: Introduce element-wise atomic memcpy and memmove intrinsics

Sanjoy Das via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 16 16:40:43 PST 2016

sanjoy added inline comments.

Comment at: docs/LangRef.rst:12697
+If the ``isvolatile`` parameter is ``true``, this call is
+a :ref:`volatile operation <volatile>`.
sanjoy wrote:
> Given that you're explicitly not passing this parameter to ``_llvm_memcpy_element_atomic``, perhaps this isn't needed?
I see you've already replied to this before -- it would be used as a switch to disable all optimizations.

However, what is the use case for this?  I'd imagine the motivation behind emitting this intrinsic would be to enable memcpy related optimizations and better codegen.  If a user does not want optimizations, perhaps they can just emit a loop with volatile loads and stores?  Or are you trying to cater to a use case of when a user wants good codegen (i.e. they want to call into a optimized runtime intrinsic) but do not want memcpy optimizations?  In that case, why won't they call ``__llvm_memcpy_element_atomic`` directly?


More information about the llvm-commits mailing list