[PATCH] D77122: [DOC] Remove too strong restriction for ‘llvm.experimental.gc.statepoint’ Intrinsic

[Serguei Katkov via Phabricator via llvm-commits]

skatkov created this revision.
skatkov added reviewers: reames, dantrushin.

The requirement for deopt parameter to be in gc parameter if it can
be modified by GC is very strong and difficult to follow.

The key example of why this can't work:
%p1 = bitcast i8* %p to i8*
statepoint [gc = (%p1)], [deopt = (%p1)]

The optimizer is allowed to replace either use (or both) of %p1 with %p. If it updates only one of the two (entirely legal), the two sets do not overlap.

So this change removes the strong wording and just mention that some implementation specific GC value can be modified.


https://reviews.llvm.org/D77122

Files:
  llvm/docs/Statepoints.rst


Index: llvm/docs/Statepoints.rst
===================================================================
--- llvm/docs/Statepoints.rst
+++ llvm/docs/Statepoints.rst
@@ -523,10 +523,9 @@
 
 The 'deopt parameters' arguments contain an arbitrary list of Values
 which is meaningful to the runtime.  The runtime may read any of these
-values, but is assumed not to modify them.  If the garbage collector
-might need to modify one of these values, it must also be listed in
-the 'gc pointer' argument list.  The '# deopt args' field indicates
-how many operands are to be interpreted as 'deopt parameters'.
+values, but is assumed not to modify them until the garbage collector
+might need to modify one of these values.  The '# deopt args' field
+indicates how many operands are to be interpreted as 'deopt parameters'.
 
 The 'gc parameters' arguments contain every pointer to a garbage
 collector object which potentially needs to be updated by the garbage


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D77122.253810.patch
Type: text/x-patch
Size: 951 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200331/8e76a9a5/attachment-0001.bin>