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

[Anna Thomas via Phabricator via llvm-commits]

anna added a comment.

Hi Artur, just to explicitly state out:

> But element atomic memcpy/memmove intrinsic calls might be generated by the optimizer, which is not aware of this coupling. If statepoints without deopt into are not allowed and we see a non-leaf memcpy/memmove without deopt state we treat it as a leaf copy and don't produce a statepoint

If a long running loop of loads and stores are converted to atomic memcpy (through loop idiom recognize for example) and we don't produce a statepoint - this will make the memcpy non GC parseable, which is erroneous. So, it is the responsibility of such runtimes to also introduce some mechanism to prevent long running loops from being converted to memcpys (such as having safepoint requests within the loop thereby preventing long running loops from being converted to memcpy: https://llvm.org/docs/Statepoints.html#id27).


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

https://reviews.llvm.org/D88861