revert clGetEventInfo returning CL_COMPLETE is a sync point (#1558)

Author: bashbaug

api/opencl_architecture.asciidoc

@@ -1976,11 +1976,6 @@ following:
     wait-for-events function on *E* (e.g. the {clWaitForEvents} function
     called from a host thread), then *E* global-synchronizes-with that
     wait-for-events function call.
-    ** Additionally, for OpenCL 3.1 and newer, *E* global-synchronizes-with an
-       API call *X* that observes that the status of *E* is complete.
-       For example, if a host thread queries the execution status of *E* using
-       {clGetEventInfo}, and the execution status is {CL_COMPLETE}, then *E*
-       global-synchronizes-with that call to {clGetEventInfo}.
   . If commands *C* and *C1* are enqueued in that sequence onto an in-order
     command-queue, then the event (including the event implied between *C*
     and *C1* due to the in-order queue) signaling *C*'s completion

api/opencl_runtime_layer.asciidoc

@@ -12946,13 +12946,16 @@ endif::cl_khr_semaphore[]
 
 |====
 
-Prior to OpenCL 3.1, using {clGetEventInfo} to determine if a command identified
-by _event_ has finished execution (i.e. whether
-{CL_EVENT_COMMAND_EXECUTION_STATUS} returns {CL_COMPLETE}) is not a
-synchronization point.
-For OpenCL 3.1 and newer, if a call to {clGetEventInfo} to determine the
-execution status of a command identified by _event_ returns {CL_COMPLETE}, then
-the call to {clGetEventInfo} is a synchronization point.
+[NOTE]
+====
+Calling {clGetEventInfo} with {CL_EVENT_COMMAND_EXECUTION_STATUS} is intended to
+be a lightweight query, therefore it is not a host synchronization point.
+This means that _event_ does not global-synchronize-with the call to
+{clGetEventInfo}, even if the returned execution status is {CL_COMPLETE}.
+When a host synchronization point is needed, call a function that waits on the
+event instead, such as {clWaitForEvents}.
+Refer to the <<memory-consistency-model, memory consistency model>> for details.
+====
 
 // refError