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

[skatkov]

Summary

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.

[reames]

LGTM w/required change.

llvm/docs/Statepoints.rst

524–525

Just drop this sentence:
"The runtime may read any of these ​values, but is assumed not to modify them until the garbage collector might need to modify one of these values. "

It's tempting to try to describe the interaction around stack slots shared between deopt and GC values here, but I couldn't find wording which wasn't simply confusing in a different way. For the moment, let's just leave that aspect undocumented.

llvm/docs/Statepoints.rst

 The 'transition parameters' arguments contain an arbitrary list of
 Values which need to be passed to GC transition code. They will be
 lowered and passed as operands to the appropriate GC_TRANSITION nodes
 in the selection DAG. It is assumed that these arguments must be
 available before and after (but not necessarily during) the execution
 of the callee. The '# transition args' field indicates how many operands
 are to be interpreted as 'transition parameters'.
 
 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'.
+which is meaningful to the runtime.  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
 collector.  Note that the argument list must explicitly contain a base
 pointer for every derived pointer listed.  The order of arguments is
 unimportant.  Unlike the other variable length parameter sets, this
 list is not length prefixed.