Adress more PR feedback

Signed-off-by: Lukas Sommer <[email protected]>

Author: sommerlukas

sycl/doc/extensions/experimental/sycl_ext_codeplay_kernel_fusion.asciidoc

@@ -51,9 +51,10 @@ not rely on APIs defined in this specification.*
 [NOTE]
 ====
 There is a link:../proposed/sycl_ext_oneapi_graph_fusion.asciidoc[follow-up
-proposal] for fusion based on the SYCL graph API. That proposal continues some
-of the ideas presented in this proposal, but uses the more versatile SYCL graphs
-API to define the sequence of kernels to execute. 
+proposal] for fusion based on the https://github.com/intel/llvm/pull/5626[SYCL
+graph API]. That proposal continues some of the ideas presented in this
+proposal, but uses the more versatile SYCL graphs API to define the sequence of
+kernels to execute.
 
 Once accepted and implemented, the new proposal will supersede this proposal.
 ====

sycl/doc/extensions/proposed/sycl_ext_oneapi_graph_fusion.asciidoc

@@ -63,7 +63,7 @@ and expose additional optimization opportunities.
 
 One of those further optimizations enabled by the graphs proposal is _kernel
 fusion_. Fusing two or more kernels executing on the same device into a single
-kernel launch can further reduce runtime overhead and enable futher kernel
+kernel launch can further reduce runtime overhead and enable further kernel
 optimizations such as dataflow internalization discussed below.
 
 This proposal is a continuation of many of the ideas of the initial