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

[Philip Reames via Phabricator via llvm-commits]

reames 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:
> 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?
In general, we want to implement two families of optimizations:
- target function recognition to intrinsic matching
- lowering of intrinsics to IR for small sizes

We need the volatile flag to know that the later isn't legal.  


https://reviews.llvm.org/D27133