Merge branch 'sycl' into bf16_builtins

Author: t4c1

.github/CODEOWNERS

@@ -22,7 +22,7 @@ libdevice/ @intel/llvm-reviewers-runtime
 sycl/ @intel/llvm-reviewers-runtime
 
 # Documentation
-sycl/ReleaseNotes.md @intel/dpcpp-doc-reviewers
+sycl/ReleaseNotes.md @intel/dpcpp-doc-reviewers @tfzhu
 sycl/doc/ @intel/dpcpp-doc-reviewers
 sycl/doc/design/ @intel/dpcpp-specification-reviewers
 sycl/doc/design/spirv-extensions/ @intel/dpcpp-spirv-doc-reviewers
@@ -50,5 +50,6 @@ clang/tools/clang-offload-*/ @intel/dpcpp-tools-reviewers
 # Explicit SIMD
 ESIMD/ @intel/dpcpp-esimd-reviewers
 esimd/ @intel/dpcpp-esimd-reviewers
-sycl/include/sycl/ext/intel/experimental/esimd.hpp @intel/dpcpp-esimd-reviewers
+sycl/include/sycl/ext/intel/esimd.hpp @intel/dpcpp-esimd-reviewers
 sycl/doc/extensions/experimental/sycl_ext_intel_esimd/ @intel/dpcpp-esimd-reviewers
+llvm/lib/SYCLLowerIR/CMakeLists.txt @intel/dpcpp-tools-reviewers @intel/dpcpp-esimd-reviewers

.github/workflows/sycl_cleanup.yml

@@ -0,0 +1,32 @@
+name: Cleanup
+
+on:
+  workflow_run:
+    workflows:
+    - SYCL
+    - SYCL Nightly Builds
+    - SYCL Post Commit
+    types: [completed]
+
+jobs:
+  cleanup:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/github-script@v6
+      with:
+        script: |
+          let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
+            owner: context.repo.owner,
+            repo: context.repo.repo,
+            run_id: context.payload.workflow_run.id,
+          });
+          let matchArtifacts = allArtifacts.data.artifacts.filter((artifact) => {
+            return artifact.name.startsWith("sycl_linux_");
+          });
+          matchArtifacts.forEach(async (artifact) => {
+            await github.rest.actions.deleteArtifact({
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+              artifact_id: artifact.id
+            });
+          });

.github/workflows/sycl_containers.yaml

@@ -10,11 +10,15 @@ on:
     paths:
       - 'devops/containers/**'
       - 'devops/dependencies.json'
+      - 'devops/scripts/install_drivers.sh'
+      - 'devops/scripts/install_build_tools.sh'
       - '.github/workflows/sycl_containers.yaml'
   pull_request:
     paths:
       - 'devops/containers/**'
       - 'devops/dependencies.json'
+      - 'devops/scripts/install_drivers.sh'
+      - 'devops/scripts/install_build_tools.sh'
       - '.github/workflows/sycl_containers.yaml'
 
 jobs:

.github/workflows/sycl_linux_build_and_test.yml

@@ -15,10 +15,6 @@ on:
         type: string
         required: false
         default: "ghcr.io/intel/llvm/ubuntu2004_build:latest"
-      build_runs_on:
-        type: string
-        required: false
-        default: "build"
       build_ref:
         type: string
         required: false
@@ -43,7 +39,7 @@ on:
       intel_drivers_image:
         type: string
         required: false
-        default: "ghcr.io/intel/llvm/ubuntu2004_intel_drivers:latest"
+        default: "ghcr.io/intel/llvm/ubuntu2004_intel_drivers:unstable"
       lts_config:
         type: string
         required: false
@@ -68,7 +64,7 @@ on:
 jobs:
   build:
     name: Build + LIT
-    runs-on: ${{ inputs.build_runs_on }}
+    runs-on: [Linux, build]
     container:
       image: ${{ inputs.build_image }}
       options: -u 1001:1001

.github/workflows/sycl_nightly.yml

@@ -64,7 +64,6 @@ jobs:
     if: github.repository == 'intel/llvm'
     uses: ./.github/workflows/sycl_linux_build_and_test.yml
     with:
-      build_runs_on: build
       build_cache_root: "/__w/"
       build_cache_suffix: new_pm
       build_artifact_suffix: new_pm

.github/workflows/sycl_post_commit.yml

@@ -15,14 +15,12 @@ jobs:
     name: Linux Default
     uses: ./.github/workflows/sycl_linux_build_and_test.yml
     with:
-      build_runs_on: build
       build_cache_root: "/__w/llvm"
       build_artifact_suffix: default
   linux_no_assert:
     name: Linux (no assert)
     uses: ./.github/workflows/sycl_linux_build_and_test.yml
     with:
-      build_runs_on: build
       build_cache_root: "/__w/llvm"
       build_cache_suffix: gcc_no_assertions
       build_artifact_suffix: gcc_no_assertions

.github/workflows/sycl_precommit.yml

@@ -4,6 +4,16 @@ on:
   pull_request:
     branches:
     - sycl
+    # Do not run builds if changes are only in the following locations
+    paths-ignore:
+    - 'devops/containers/**'
+    - 'devops/scripts/install_drivers.sh'
+    - 'devops/scripts/install_build_tools.sh'
+    - 'sycl/doc/**'
+    - 'sycl/gdb/**'
+    - 'clang/docs/**'
+    - '**.md'
+    - '**.rst'
 
 jobs:
   lint:
@@ -25,7 +35,6 @@ jobs:
     if: always() && (success() || contains(github.event.pull_request.labels.*.name, 'ignore-lint'))
     uses: ./.github/workflows/sycl_linux_build_and_test.yml
     with:
-      build_runs_on: "build"
       build_cache_root: "/__w/"
       build_cache_size: "8G"
       build_artifact_suffix: "default"

CONTRIBUTING.md

@@ -15,25 +15,18 @@ these terms.
 
 ### Development
 
-**NB**: For any changes not related to DPC++, but rather to LLVM in general, it
-is strongly encouraged that you submit the patch to https://llvm.org/ directly.
-See [LLVM contribution guidelines](https://llvm.org/docs/Contributing.html)
-for more information.
-
-**NB**: A change in compiler and runtime should be accompanied with
-corresponding test changes.
-See [Test DPC++ toolchain](sycl/doc/GetStartedGuide.md#test-dpc-toolchain)
-section of Get Started guide for more information.
-
-**Note (October, 2020)**: DPC++ runtime and compiler ABI is currently in frozen
-state. This means that no ABI-breaking changes will be accepted by default.
-Project maintainers may still approve breaking changes in some cases. Please,
-see [ABI Policy Guide](sycl/doc/developer/ABIPolicyGuide.md) for more
-information.
+For any changes not related to Intel Project for LLVM\* technology, but rather
+to LLVM in general, it is strongly encouraged that you submit the patch to
+https://llvm.org/ directly.  See
+[LLVM contribution guidelines](https://llvm.org/docs/Contributing.html) for
+more information.
+
+Every change should be accompanied with corresponding test modification (adding
+new test(s), extending, removing or modifying existing test(s)).
+
+To contribute:
 
 - Create a personal fork of the project on GitHub
-  - 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)
   - [clang-format](https://clang.llvm.org/docs/ClangFormat.html) and
@@ -48,110 +41,41 @@ information.
     ./clang/tools/clang-format/git-clang-format `git merge-base origin/sycl HEAD`
     ```
 
-    to check the format of your current changes against the `origin/sycl`
-    branch.
+    to check the format of your current changes. `origin/sycl` branch is an
+    example here
     - `-f` to also correct unstaged changes
     - `--diff` to only print the diff without applying
-- Build the project following
-[Get Started Guide instructions](sycl/doc/GetStartedGuide.md#build-dpc-toolchain).
-- Run regression tests -
-[instructions](sycl/doc/GetStartedGuide.md#test-dpc-toolchain).
-
-### Tests development
-
-Every product change should be accompanied with corresponding test modification
-(adding new test(s), extending, removing or modifying existing test(s)).
-
-There are 3 types of tests which are used for DPC++ toolchain validation:
-* DPC++ in-tree tests including [check-llvm](llvm/test),
-[check-clang](clang/test), [check-llvm-spirv](llvm-spirv/test) and
-[check-sycl](sycl/test) targets stored in this repository. These tests
-should not have hardware (e.g. GPU, FPGA, etc.) or external software
-dependencies (e.g. OpenCL, Level Zero, CUDA runtimes). All tests not following
-this approach should be moved to DPC++ end-to-end or SYCL-CTS tests.
-Generally, any functional change to any of the DPC++ toolchain components
-should be accompanied by one or more tests of this type when possible. They
-allow verifying individual components and tend to be more lightweight than
-end-to-end or SYCL-CTS tests.
-
-    **General guidelines for adding DPC++ in-tree tests**:
 
-    - Use `sycl::` namespace instead of `cl::sycl::`
+#### Project-specific contribution guidelines
 
-    - Add a helpful comment describing what the test does at the beginning and
-    other comments throughout the test as necessary.
+- [Contribute to DPC++](/../sycl/sycl/doc/developer/ContributeToDPCPP.md)
 
-    - Try to follow descriptive naming convention for variables, functions as
-    much as possible.
-    Please refer to
-    [LLVM naming convention](https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly)
-
-    **DPC++ clang FE tests**:
-
-    - Include sycl mock headers as system headers.
-    Example: `-internal-isystem %S/Inputs`
-    `#include "sycl.hpp"`
-
-    - Use SYCL functions for invoking kernels from the mock header
-    `(single_task, parallel_for, parallel_for_work_group)`
-    Example:
-    ```bash
-    `#include "Inputs/sycl.hpp"`
-    sycl::queue q;
-    q.submit([&](cl::sycl::handler &h) {
-    h.single_task( { //code });
-    });
-    ```
+### Pull request
 
-    **DPC++ headers and runtime tests**:
-
-    - [check-sycl](sycl/test) target contains 2 types of tests: LIT tests and
-    unit tests. LIT tests make compile-time checks of DPC++ headers, e.g. device
-    code IR verification, static_assert tests. Unit tests check DPC++ runtime
-    behavior and do not perform any device code compilation, instead relying on
-    redefining plugin API with [PiMock](sycl/unittests/helpers/PiMock.hpp) when
-    necessary.
-
-* DPC++ end-to-end (E2E) tests which are extension to
-[LLVM\* test suite](https://github.com/intel/llvm-test-suite/tree/intel/SYCL).
-A test which requires full stack including backend runtimes (e.g. OpenCL,
-Level Zero or CUDA) should be put to DPC++ E2E test suite following
-[CONTRIBUTING](https://github.com/intel/llvm-test-suite/blob/intel/CONTRIBUTING.md).
-
-* SYCL-CTS are official 
-[Khronos\* SYCL\* conformance tests](https://github.com/KhronosGroup/SYCL-CTS).
-They verify SYCL specification compatibility. All implementation details or
-extensions are out of scope for the tests. If SYCL specification has changed
-(SYCL CTS tests conflict with recent version of SYCL specification) or change
-is required in the way the tests are built with DPC++ compiler (defined in
-[FindIntel_SYCL](https://github.com/KhronosGroup/SYCL-CTS/blob/SYCL-1.2.1/master/cmake/FindIntel_SYCL.cmake))
-pull request should be created under
-[KhronosGroup/SYCL-CTS](https://github.com/KhronosGroup/SYCL-CTS) with required
-patch.
-
-### Commit message
-
-- When writing your commit message, please make sure to follow
+- When creating your commit messages, please make sure to follow
   [LLVM developer policies](
   https://llvm.org/docs/DeveloperPolicy.html#commit-messages) on the subject.
-- For any DPC++-related commit, the `[SYCL]` tag should be present in the
-  commit message title. To a reasonable extent, additional tags can be used
-  to signify the component changed, e.g.: `[PI]`, `[CUDA]`, `[Doc]`.
-- For product changes which require modification in tests outside of the current repository
-  (see [Test DPC++ toolchain](sycl/doc/GetStartedGuide.md#test-dpc-toolchain)),
-  the commit message should contain the link to corresponding test PR, e.g.: E2E
-  test changes are available under intel/llvm-test-suite#88 or SYCL
-  conformance test changes are available under KhronosGroup/SYCL-CTS#65 (see
-  [Autolinked references and URLs](https://docs.github.com/en/free-pro-team/github/writing-on-github/autolinked-references-and-urls)
+  - [The seven rules of a great Git commit message](https://cbea.ms/git-commit)
+    are recommended read and follow.
+- To a reasonable extent, title tags can be used to signify the component
+  changed, e.g.: `[PI]`, `[CUDA]`, `[Doc]`.
+- Create a pull request (PR) for your changes following
+  [Creating a pull request instructions](https://help.github.com/articles/creating-a-pull-request/).
+  - Make sure PR has a good description explaining all of the changes made,
+    represented by commits in the PR.
+  - When PR is merged all commits are squashed and PR description is used as
+    the merged commit message.
+  - Consider splitting the large set of changes on small independent PRs that
+    can be reviewed, tested and merged independently.
+- For changes which require modification in tests outside of the current repository
+  the commit message should contain the link to corresponding test PR.
+  For example: intel/llvm-test-suite#88 or KhronosGroup/SYCL-CTS#65. (see
+  [Autolinked references and URLs](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls)
   for more details). The same message should be present both in commit
   message and in PR description.
 
 ### Review and acceptance testing
 
-- Create a pull request for your changes following [Creating a pull request
-instructions](https://help.github.com/articles/creating-a-pull-request/).
-- CI will run a signed-off check as soon as your PR is created - see the
-**check_pr** CI action results.
 - CI will run several build and functional testing checks as soon as the PR is
 approved by an Intel representative.
   - A new approval is needed if the PR was updated (e.g. during code review).
@@ -160,12 +84,14 @@ ready for merge.
 
 ### Merge
 
-Project maintainers merge pull requests using one of the following options:
+Project gatekeepers (@intel/llvm-gatekeepers) merge pull requests using [Squash
+and merge] and using PR description as the commit message, replacing all
+individual comments made per commit. Authors of the change must ensure PR
+description is up to date at the merge stage, as sometimes comments addressed
+during code reviews can invalidate original PR description. Feel free to ping
+@intel/llvm-gatekeepers if your PR is green and can be merged.
 
-- [Rebase and merge] The preferable choice for PRs containing a single commit
-- [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
+Pulldown from LLVM upstream is done through merge commits to preserve hashes of
+the original commits pulled from the LLVM community repository.
 
-*Other names and brands may be claimed as the property of others.
+<sub>\*Other names and brands may be claimed as the property of others.</sub>