Add implementation notes to range_type proposal

Signed-off-by: John Pennycook <[email protected]>

Author: Pennycook

sycl/doc/extensions/proposed/sycl_ext_oneapi_range_type.asciidoc

@@ -181,6 +181,31 @@ option, all kernels and `SYCL_EXTERNAL` functions without an explicitly
 specified `range_type` property are compiled as-if `range_type<int>` was
 specified as a property of that kernel or function.
 
+
+== Implementation notes
+
+This non-normative section provides information about one possible
+implementation of this extension.
+It is not part of the specification of the extension's API.
+
+There are several ways this extension could be implemented:
+
+- A dedicated LLVM-IR pass could recognize functions that compute an ID (e.g.,
+  `nd_item::get_global_id`), check whether the static call tree comes from a
+  kernel or function decorated with `range_type`, and then conditionally insert
+  an equivalent of `__builtin_assume`.
+
+- The existing `__builtin_assume` intrinsic in `__SYCL_ASSUME_INT` could be
+  replaced by a new (but similar) SPIR-V intrinsic, shifting range-type
+  optimizations to the device compiler.
+  This could take the form of a dedicated `__spirv_AssumeInRange` intrinsic,
+  or a general `__spirv_Assume` intrinsic coupled with a `__spirv_MaxRange`
+  value.
+
+Ideally, the solution should not generate SPIR-V modules that require new
+extensions if `range_type` is not used.
+
+
 == Issues
 
 None.