[SYCL] Rename project to oneAPI DPC++ Compiler (#1249)

Rename project and fixing docs accordingly to new project name.

Signed-off-by: Pavel V Chupin <[email protected]>

Author: pvchupin

CONTRIBUTING.md

@@ -1,7 +1,7 @@
 # Contributing
 
 ## License
-Intel Project for LLVM* technology is licensed under the terms of the
+Intel Project for LLVM\* technology is licensed under the terms of the
 Apache-2.0 with LLVM-exception license ([LICENSE.txt](llvm/LICENSE.TXT))
 to ensure our ability to contribute this project to the LLVM project
 under the same license.
@@ -70,11 +70,11 @@ commit automatically with `git commit -s`.
 ### Development
 
 - Create a personal fork of the project on GitHub
-- Use **sycl** branch as baseline for your changes
+  - For the DPC++ Compiler project, use **sycl** branch as baseline for your
+    changes. See [Get Started Guide](sycl/doc/GetStartedGuide.md).
 - Prepare your patch (follow
   [LLVM coding standards](https://llvm.org/docs/CodingStandards.html))
-- Build the project and run all tests (see
-[GetStartedWithSYCLCompiler.md](sycl/doc/GetStartedWithSYCLCompiler.md))
+- Build the project and run all tests
 
 ### Review and acceptance testing
 
@@ -94,4 +94,8 @@ Project maintainers merge pull requests using one of the following options:
 - [Squash and merge] Used when there are multiple commits in the PR
   - Squashing is done to make sure that the project is buildable on any commit
 - [Create a merge commit] Used for LLVM pull-down PRs to preserve hashes of the
-commits pulled from the LLVM community repository
+commits pulled from the LLVM community repository
+
+
+*Other names and brands may be claimed as the property of others.
+

README.md

@@ -1,24 +1,28 @@
-# Intel Project for LLVM* technology
+# Intel Project for LLVM\* technology
 
 ## Introduction
 
 Intel staging area for llvm.org contribution.
 Home for Intel LLVM-based projects:
- - SYCL* Compiler and Runtimes - compiler and runtime libraries for SYCL ([https://www.khronos.org/sycl/](https://www.khronos.org/sycl/)). See **sycl** branch.
+ - oneAPI Data Parallel C++ compiler - see **sycl** branch. More information on
+   oneAPI and DPC++ is available at
+([https://www.oneapi.com/](https://www.oneapi.com/))
 
 ## License
 See [LICENSE.txt](sycl/LICENSE.TXT) for details.
 
-
 ## Contributing
 See [CONTRIBUTING.md](CONTRIBUTING.md) for details.
 
 ## Sub-projects Documentation
- - SYCL Compiler and Runtimes - See [GetStartedWithSYCLCompiler.md](sycl/doc/GetStartedWithSYCLCompiler.md)
+ - oneAPI Data Parallel C++ compiler - See
+   [GetStartedGuide.md](sycl/doc/GetStartedGuide.md)
 
-*Other names and brands may be claimed as the property of others.
+## DPC++ extensions
 
-## SYCL Extension Proposal Documents
+DPC++ is an open, cross-architecture language built upon the ISO C++ and Khronos
+SYCL\* standards. DPC++ extends these standards with a number of extensions,
+which can be found in [sycl/doc/extensions](sycl/doc/extensions) directory.
 
-See [sycl/doc/extensions](sycl/doc/extensions)
+\*Other names and brands may be claimed as the property of others.
 

sycl/doc/SYCLCompilerAndRuntimeDesign.md renamed to sycl/doc/CompilerAndRuntimeDesign.md

@@ -1,18 +1,18 @@
-# SYCL\* Compiler and Runtime architecture design
+# oneAPI DPC++ Compiler and Runtime architecture design
 
 ## Introduction
 
-This document describes the architecture of the SYCL compiler and runtime
-library.  Base SYCL specification version is
-[1.2.1](https://www.khronos.org/registry/SYCL/specs/sycl-1.2.1.pdf).
+This document describes the architecture of the DPC++ compiler and runtime
+library. For DPC++ specification see
+[spec](https://spec.oneapi.com/versions/latest/elements/dpcpp/source/index.html).
 
-## SYCL Compiler architecture
+## DPC++ Compiler architecture
 
-SYCL application compilation flow:
+DPC++ application compilation flow:
 
-![High level component diagram for SYCL Compiler](Compiler-HLD.svg)
+![High level component diagram for DPC++ Compiler](images/Compiler-HLD.svg)
 
-SYCL compiler logically can be split into the host compiler and a number of
+DPC++ compiler logically can be split into the host compiler and a number of
 device compilers—one per each supported target. Clang driver orchestrates the
 compilation process, it will invoke the device compiler once per each requested
 target, then it will invoke the host compiler to compile the host part of a
@@ -31,7 +31,7 @@ applies additional restrictions on the device code (e.g. no exceptions or
 virtual calls), generates LLVM IR for the device code only and "integration
 header" which provides information like kernel name, parameters order and data
 type for the runtime library.
-- **Middle-end** - transforms the initial LLVM IR* to get consumed by the
+- **Middle-end** - transforms the initial LLVM IR to get consumed by the
 back-end. Today middle-end transformations include just a couple of passes:
   - Optionally: Address space inference pass
   - TBD: potentially the middle-end optimizer can run any LLVM IR
@@ -78,7 +78,7 @@ Q.submit([&](handler& cgh) {
 ...
 ```
 
-In this example, the SYCL compiler needs to compile the lambda expression passed
+In this example, the compiler needs to compile the lambda expression passed
 to the `cl::sycl::handler::parallel_for` method, as well as the function `foo`
 called from the lambda expression for the device.
 The compiler must also ignore the `bar` function when we compile the
@@ -87,9 +87,9 @@ portion of the source code (the contents of the lambda expression passed to the
 `cl::sycl::handler::parallel_for` and any function called from this lambda
 expression).
 
-The current approach is to use the SYCL kernel attribute in the SYCL runtime to
+The current approach is to use the SYCL kernel attribute in the runtime to
 mark code passed to `cl::sycl::handler::parallel_for` as "kernel functions".
-The SYCL runtime library can't mark foo as "device" code - this is a compiler
+The runtime library can't mark foo as "device" code - this is a compiler
 job: to traverse all symbols accessible from kernel functions and add them to
 the "device part" of the code marking them with the new SYCL device attribute.
 
@@ -160,8 +160,8 @@ must be passed to the clang driver:
 
 `-fsycl`
 
-With this option specified, the driver will invoke the host SYCL compiler and a
-number of device compilers for targets specified in the `-fsycl-targets`
+With this option specified, the driver will invoke the host compiler and a
+number of SYCL device compilers for targets specified in the `-fsycl-targets`
 option.  If `-fsycl-targets` is not specified, then single SPIR-V target is
 assumed, and single device compiler for this target is invoked.
 
@@ -188,7 +188,7 @@ a set of target architectures for which to compile device code. By default the
 compiler generates SPIR-V and OpenCL device JIT compiler produces native target
 binary.
 
-There are existing options for OpenMP* offload:
+There are existing options for OpenMP\* offload:
 
 `-fopenmp-targets=triple1,triple2`
 
@@ -477,7 +477,7 @@ produced by OpenCL C front-end compiler.
 It's a regular function, which can conflict with user code produced from C++
 source.
 
-SYCL compiler uses modified solution developed for OpenCL C++ compiler
+DPC++ compiler uses modified solution developed for OpenCL C++ compiler
 prototype:
 
 - Compiler: https://github.com/KhronosGroup/SPIR/tree/spirv-1.1
@@ -546,17 +546,11 @@ compiler:
 
 ### Compiler/Runtime interface
 
-## SYCL Runtime architecture
+## DPC++ Runtime architecture
 
 *TBD*
 
-## Supported extensions
+## DPC++ Language extensions to SYCL
 
-- [Intel subgroups](extensions/SubGroupNDRange/SubGroupNDRange.md)
+List of language extensions can be found at [extensions](extensions)
 
-## Unsupported extensions/proposals
-
-- [Ordered queue](extensions/OrderedQueue/OrderedQueue.adoc)
-- [Unified shared memory](extensions/USM/USM.adoc)
-
-\*Other names and brands may be claimed as the property of others.

sycl/doc/SYCLEnvironmentVariables.md renamed to sycl/doc/EnvironmentVariables.md

@@ -1,32 +1,32 @@
 # Overview
 
-This file describes environment variables that are having effect on SYCL compiler and run-time.
+This file describes environment variables that are having effect on DPC++ compiler and runtime.
 
-# Controlling SYCL RT
+# Controlling DPC++ RT
 
 **Warning:** the environment variables described in this document are used for
-development and debugging of SYCL runtime and compiler. Their semantics are
+development and debugging of DPC++ compiler and runtime. Their semantics are
 subject to change. Do not rely on these variables in production code.
 
 | Environment variable | Values | Description |
 | -------------------- | ------ | ----------- |
-| SYCL_PI_TRACE | Any(*) | Force tracing of PI calls to stderr. |
+| SYCL_PI_TRACE | Any(\*) | Force tracing of PI calls to stderr. |
 | SYCL_BE | PI_OPENCL, PI_OTHER | When SYCL RT is built with PI this controls which plugin to use. Default value is PI_OPENCL. |
 | SYCL_DEVICE_TYPE | One of: CPU, GPU, ACC, HOST | Force SYCL to use the specified device type. If unset, default selection rules are applied. If set to any unlisted value, this control has no effect. If the requested device type is not found, a `cl::sycl::runtime_error` exception is thrown. If a non-default device selector is used, a device must satisfy both the selector and this control to be chosen. This control only has effect on devices created with a selector. |
 | SYCL_PROGRAM_COMPILE_OPTIONS | String of valid OpenCL compile options | Override compile options for all programs. |
 | SYCL_PROGRAM_LINK_OPTIONS | String of valid OpenCL link options | Override link options for all programs. |
 | SYCL_USE_KERNEL_SPV | Path to the SPIR-V binary | Load device image from the specified file. If runtime is unable to read the file, `cl::sycl::runtime_error` exception is thrown.|
-| SYCL_DUMP_IMAGES | Any(*) | Dump device image binaries to file. Control has no effect if SYCL_USE_KERNEL_SPV is set. |
+| SYCL_DUMP_IMAGES | Any(\*) | Dump device image binaries to file. Control has no effect if SYCL_USE_KERNEL_SPV is set. |
 | SYCL_PRINT_EXECUTION_GRAPH | Described [below](#sycl_print_execution_graph-options) | Print execution graph to DOT text file. |
-| SYCL_DISABLE_EXECUTION_GRAPH_CLEANUP | Any(*) | Disable cleanup of finished command nodes at host-device synchronization points. |
-| SYCL_THROW_ON_BLOCK | Any(*) | Throw an exception on attempt to wait for a blocked command.  |
+| SYCL_DISABLE_EXECUTION_GRAPH_CLEANUP | Any(\*) | Disable cleanup of finished command nodes at host-device synchronization points. |
+| SYCL_THROW_ON_BLOCK | Any(\*) | Throw an exception on attempt to wait for a blocked command.  |
 | SYCL_DEVICELIB_INHIBIT_NATIVE | String of device library extensions (separated by a whitespace) | Do not rely on device native support for devicelib extensions listed in this option. |
-| SYCL_DEVICE_ALLOWLIST | A list of devices and their minimum driver version following the pattern: DeviceName:{{XXX}},DriverVersion:{{X.Y.Z.W}}. Also may contain PlatformName and PlatformVersion | Filter out devices that do not match the pattern specified. Regular expression can be passed and the SYCL RT will select only those devices which satisfy the regex. |
+| SYCL_DEVICE_ALLOWLIST | A list of devices and their minimum driver version following the pattern: DeviceName:{{XXX}},DriverVersion:{{X.Y.Z.W}}. Also may contain PlatformName and PlatformVersion | Filter out devices that do not match the pattern specified. Regular expression can be passed and the DPC++ runtime will select only those devices which satisfy the regex. |
 `(*) Note: Any means this environment variable is effective when set to any non-null value.`
 
 ## SYCL_PRINT_EXECUTION_GRAPH Options
 
-SYCL_PRINT_EXECUTION_GRAPH can accept one or more comma separated values from table below
+SYCL_PRINT_EXECUTION_GRAPH can accept one or more comma separated values from the table below
 
 | Option | Description |
 | ------ | ----------- |

sycl/doc/FAQ.md

@@ -2,51 +2,51 @@
 
 **Table of contents**
 
-1. [Developing with SYCL](#developing-with-sycl)
-1. [Using applications built with SYCL](#using-applications-built-with-sycl)
+1. [Developing with DPC++](#developing-with-dpc)
+1. [Using applications built with DPC++](#using-applications-built-with-dpc)
 1. [Common issues](#common-issues)
 1. [Device specific questions and issues](#device-specific-questions-and-issues)
 
 
-## Developing with SYCL
+## Developing with DPC++
 
-### Q: What do I need to start developing with SYCL?
-**A:** To get the full SYCL experience you need a SYCL-capable compiler. Intel
-SYCL compiler provides you with both host and device side compilation. Another
+### Q: What do I need to start developing with DPC++?
+**A:** To get the full DPC++ experience you need oneAPI DPC++ compiler. DPC++
+compiler provides you with both host and device side compilation. Another
 requirement for code offloading to specialized devices is a compatible OpenCL
-runtime. Our [Get Started Guide](GetStartedWithSYCLCompiler.md) will help you
-set up a proper environment. To learn more about using the SYCL compiler, please
-refer to [User Manual](SYCLCompilerUserManual.md). If using a special compiler
+runtime. Our [Get Started Guide](GetStartedGuide.md) will help you
+set up a proper environment. To learn more about using the DPC++ compiler,
+please refer to [Users Manual](UsersManual.md). If using a special compiler
 is not an option for you and/or you would like to experiment without offloading
-code to non-host devices, you can exploit SYCL's host device feature. This gives
-you the ability to use any C++11 compiler. You will need to link your
-application with the SYCL Runtime library and provide a path to the SYCL headers
-directory. Please, refer to your compiler manual to learn about specific build
-options.
+code to non-host devices, you can exploit SYCL's host device feature. This
+gives you the ability to use any C++11 compiler. You will need to link your
+application with the DPC++ Runtime library and provide a path to the SYCL
+headers directory. Please, refer to your compiler manual to learn about
+specific build options.
 
-### Q: How are SYCL compilation phases different from those of a usual C++ compiler? Can I customize this flow for my applications?
+### Q: How are DPC++ compilation phases different from those of a usual C++ compiler? Can I customize this flow for my applications?
 **A:** Due to the fact that both host and device code need to be compiled and
-linked into the final binary, the compilation steps sequence is more complicated
-compared to the usual C++ flow.
+linked into the final binary, the compilation steps sequence is more
+complicated compared to the usual C++ flow.
 
-In general, we encourage our users to rely on the SYCL Compiler for handling all
-of the compilation phases "under the hood". However, thorough understanding of
-the above-described steps may allow you to customize your compilation by invoking
-different phases manually. As an example, you could:
+In general, we encourage our users to rely on the DPC++ Compiler for handling
+all of the compilation phases "under the hood". However, thorough understanding
+of the above-described steps may allow you to customize your compilation by
+invoking different phases manually. As an example, you could:
 1. preprocess your host code with another C++-capable compiler;
-2. turn to the SYCL compiler for generating the integration header and compiling
-the device code for the needed target(s);
+2. turn to the DPC++ compiler for generating the integration header and
+compiling the device code for the needed target(s);
 3. use your preferred host compiler from 1) to compile your preprocessed host
 code and the integration header into a host object file;
 4. link the host object file and the device image(s) into the final executable.
 
-To learn more about the concepts behind this flow, and the SYCL Compiler
+To learn more about the concepts behind this flow, and the DPC++ Compiler
 internals as such, we welcome you to study our
-[SYCL Compiler and Runtime architecture design](SYCLCompilerAndRuntimeDesign.md)
+[DPC++ Compiler and Runtime architecture design](CompilerAndRuntimeDesign.md)
 document.
 
 
-## Using applications built with SYCL
+## Using applications built with DPC++
 
 ### Q: What happens if I run my application on a machine without OpenCL?
 **A:** If you use the default SYCL device selector (or any other selector that
@@ -56,7 +56,7 @@ Otherwise, an exception will be thrown.
 
 ## Common issues
 
-### Q: SYCL application complains about missing libsycl.so (or sycl.dll) library.
+### Q: DPC++ application complains about missing libsycl.so (or sycl.dll) library.
 Linux:
 ```
 $ ./app
@@ -66,15 +66,16 @@ Windows:
 
 ![Error screen](images/missing_sycl_dll.png)
 
-*The code execution cannot proceed because sycl.dll was not found. Reinstalling the program may fix this problem.*
+*The code execution cannot proceed because sycl.dll was not found. Reinstalling
+the program may fix this problem.*
 
-**A:** The SYCL Runtime library is required to run SYCL-enabled applications.
+**A:** The DPC++ Runtime library is required to run DPC++ applications.
 While compiler driver is able to find the library and link against it, your
-operating system may struggle. Make sure that the location of the SYCL Runtime
+operating system may struggle. Make sure that the location of the DPC++ Runtime
 library is listed in the correct environment variable: `LD_LIBRARY_PATH`
 (for Linux) or `LIB` (for Windows).
 
-### Q: SYCL fails to compile device code that uses STD functions.
+### Q: DPC++ Compiler fails to compile device code that uses STD functions.
 Example error message:
 ```
 In file included from example.cpp:1:
@@ -119,10 +120,10 @@ specification.
 
 ## Device specific questions and issues
 
-### Q: What devices are supported by Intel SYCL compiler?
-**A:** By design, SYCL is closely connected to OpenCL, which is used to offload
-code to specialized devices. Intel SYCL compiler currently makes use of SPIR-V,
-a portable intermediate representation format. It is a core feature of
+### Q: What devices are supported by DPC++ compiler?
+**A:** By design, DPC++ and SYCL are closely connected to OpenCL, which is used
+to offload code to specialized devices. DPC++ compiler currently makes use of
+SPIR-V, a portable intermediate representation format. It is a core feature of
 OpenCL 2.1, so any device, capable of OpenCL 2.1, should be supported.
 Otherwise, your OpenCL device must support `cl_khr_il_program` extension.
 
@@ -132,17 +133,17 @@ the offload target for kernel execution. Since the device code is also compiled
 for the host CPU and no JIT is required, you can easily use any classic C++
 debugging tools of your choice for the host device code.
 
-Furthermore, developers can extend capabilities of the SYCL Runtime to
-non-OpenCL devices by writing correspondent plugins. To learn more, please check
-out our [Plugin Interface Guide](SYCLPluginInterface.md).
+Furthermore, developers can extend capabilities of the DPC++ Runtime to
+non-OpenCL devices by writing correspondent plugins. To learn more, please
+check out our [Plugin Interface Guide](PluginInterface.md).
 
-### Q: SYCL applications hang on Intel GPUs while working well on other devices
+### Q: DPC++ applications hang on Intel GPUs while working well on other devices
 **A:** One of the common reasons is Intel GPUs feature called "hang check".
 If your workload runs for more than a certain amount of time, it will be killed
-by hardware. From the application point of view this looks like a hang. To allow
-heavy kernels to be executed, disable hang check. **Please, note that other apps
-on your system may contain bugs, and disabling "hang check" may lead to real
-hangs.**
+by hardware. From the application point of view this looks like a hang. To
+allow heavy kernels to be executed, disable hang check. **Please, note that
+other apps on your system may contain bugs, and disabling "hang check" may lead
+to real hangs.**
 
 You can find out more about hang check and how to disable it on
 [this page](https://software.intel.com/en-us/articles/installation-guide-for-intel-oneapi-toolkits).