Remove references to SYCL general/generic

Earlier commits reworded several sentences to remove references to
"SYCL general" and "SYCL generic" by referring explicitly to backends instead.
This commit completes that work by removing the remaining references to these
concepts.

adoc/chapters/architecture.adoc

@@ -300,22 +300,21 @@ across <<backend, SYCL backends>>.
 
 USM allocations are subject to the limitations described in <<sec:usm>>.
 
-When a SYCL application runs on any number of <<backend, SYCL backends>> without
-relying on any <<backend>>-specific behavior or interoperability, it is said to
-be a SYCL general application, and it is expected to run in any SYCL-conformant
+When a SYCL application runs without relying on any <<backend>>-specific
+behavior or interoperability, it is expected to run on any SYCL-conformant
 implementation that supports the required features for the application.
 
 
 === Platform mixed version support
 
-The SYCL generic programming model exposes a number of <<platform,platforms>>,
-each of them either empty or exposing a number of <<device,devices>>.
+The SYCL programming model exposes a number of <<platform,platforms>>, each of
+them either empty or exposing a number of <<device,devices>>.
 Each platform is bound to no more than one <<backend>>.
 If the platform is bound to a backend, the devices associated with that platform
 are associated with that backend.
 
-Although the APIs in the SYCL generic programming model are defined according to
-this specification and their version is indicated by the macro
+Although most APIs in the SYCL programming model are defined according to this
+specification and their version is indicated by the macro
 [code]#SYCL_LANGUAGE_VERSION#, this does not apply to APIs exposed by the
 <<backend, SYCL backends>>.
 Each <<backend>> provides its own document that defines its APIs, and that
@@ -1608,16 +1607,16 @@ Device discovery will return all <<device,devices>> from all
 
 There are two styles of developing a SYCL application:
 
-. writing a pure SYCL generic application;
+. writing a SYCL application that works with any <<backend>>;
 . writing a SYCL application that relies on some <<backend>> specific behavior.
 
 When users follow 1., there is no assumption about what <<backend>> will be used
 during compilation or execution of the SYCL application.
 Therefore, the <<backend-api>> is not assumed to be available to the developer.
 Only standard {cpp} types and interfaces are assumed to be available, as
 described in <<sec:progmodel.cpp>>.
-Users only need to include the [code]#<sycl/sycl.hpp># header to write a SYCL
-generic application.
+Users only need to include the [code]#<sycl/sycl.hpp># header to write such an
+application.
 
 On the other hand, when users follow 2., they must know what <<backend-api>>s
 they are using.

adoc/chapters/device_compiler.adoc

@@ -676,13 +676,13 @@ associated with an aspect that is not listed in the attribute.
 == Address-space deduction
 
 {cpp} has no type-level support to represent address spaces.
-As a consequence, the SYCL generic programming model does not directly affect
-the {cpp} type of unannotated pointers and references.
+As a consequence, the SYCL programming model does not directly affect the {cpp}
+type of unannotated pointers and references.
 
-Source level guarantees about address spaces in the SYCL generic programming
-model can only be achieved using pointer classes (instances of
-[code]#multi_ptr#), which are regular classes that represent pointers to data
-stored in the corresponding address spaces.
+Source level guarantees about address spaces in the SYCL programming model can
+only be achieved using pointer classes (instances of [code]#multi_ptr#), which
+are regular classes that represent pointers to data stored in the corresponding
+address spaces.
 
 In SYCL, the address space of pointer and references are derived from:
 

adoc/chapters/host_backend.adoc

@@ -49,7 +49,7 @@ kernel execution model.
 Kernel math library functions on the host must conform to OpenCL math precision
 requirements.
 The SYCL host device needs to be queried for the capabilities it provides.
-This ensures consistency when executing any SYCL general application.
+This ensures consistency when executing any SYCL application.
 
 The <<host-device>> must report as supporting images and therefore support the
 minimum image formats.

adoc/chapters/opencl_backend.adoc

@@ -4,10 +4,10 @@
 [[chapter:opencl-backend]]
 = OpenCL backend specification
 
-This chapter describes how the SYCL general programming model is mapped on top
-of OpenCL, and how the SYCL generic interoperability interface must be
-implemented by vendors providing SYCL for OpenCL implementations to ensure SYCL
-applications written for the OpenCL backend are interoperable.
+This chapter describes how the SYCL programming model is mapped on top of
+OpenCL, and how the SYCL interoperability interface must be implemented by
+vendors providing SYCL for OpenCL implementations to ensure SYCL applications
+written for the OpenCL backend are interoperable.
 
 
 [[sec:opencl:native-interop-application]]
@@ -669,8 +669,8 @@ bool has_extension(const sycl::device& syclDevice, const std::string& extension)
 === Reference counting
 
 Most OpenCL objects are reference counted.
-The SYCL general programming model doesn't require that native objects are
-reference counted.
+The SYCL programming model doesn't require that native objects are reference
+counted.
 However, for convenience, the following function is provided in the
 [code]#sycl::opencl# namespace.
 

adoc/chapters/programming_interface.adoc

@@ -9083,7 +9083,7 @@ parameters are the same.
 
 In SYCL, there are five different address spaces: global, local, constant,
 private and generic.
-In a SYCL generic implementation, types are not affected by the address spaces.
+The type of a pointer is not typically affected by its address space.
 However, there are situations where users need to explicitly carry address
 spaces in the type.
 For example: