[PATCH] D88861: GC-parseable element atomic memcpy/memmove

[Artur Pilipenko via Phabricator via llvm-commits]

apilipenko added inline comments.


================
Comment at: llvm/lib/Transforms/Utils/Local.cpp:2680
+             IID != Intrinsic::experimental_deoptimize &&
+             IID != Intrinsic::memcpy_element_unordered_atomic &&
+             IID != Intrinsic::memmove_element_unordered_atomic;
----------------
skatkov wrote:
> I'm a bit confused here. RS4GC consider memcpy/memove as gc leaf if there is no deopt bundle.
> Here we do not check for deopt bundle. Is it ok?
callsGCLeafFunction returns true if the call is guaranteed to never safepoint. If a memcpy/memmove call is marked as gc-leaf it is guaranteed to be a leaf call, i.e. it will never take a safepoint. Otherwise the call *may* take a safepoint, but doesn't have to. This is reflected in the documentation: 
> Note that a GC parseable copy operation is not required to take a safepoint. For example, a short copy operation may be performed without taking a safepoint.

Interactions with deopt bundles is an implementation detail of RS4GC. For a memcpy/memmove call which may safepoint (i.e. doesn't have gc-leaf attribute) RS4GC is allowed to generate a leaf call which will never safepoint. If runtime requires deopt information to be associated with every safepoint (rs4gc-allow-statepoint-with-no-deopt-info=false) and RS4GC can not satisfy this requirement for a memcpy/memmove call it will generate a leaf call.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88861/new/

https://reviews.llvm.org/D88861