[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>`.
> 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