Merge remote-tracking branch 'origin/sycl' into mem_mutex

Author: againull

.github/CODEOWNERS

@@ -25,8 +25,8 @@ sycl/ @intel/llvm-reviewers-runtime
 sycl/ReleaseNotes.md @intel/dpcpp-doc-reviewers
 sycl/doc/ @intel/dpcpp-doc-reviewers
 sycl/doc/design/ @intel/dpcpp-specification-reviewers
+sycl/doc/design/spirv-extensions/ @intel/dpcpp-spirv-doc-reviewers
 sycl/doc/extensions/ @intel/dpcpp-specification-reviewers
-sycl/doc/extensions/SPIRV/ @intel/dpcpp-spirv-doc-reviewers
 
 # Level Zero plugin
 sycl/plugins/level_zero/ @intel/dpcpp-l0-pi-reviewers
@@ -51,4 +51,4 @@ clang/tools/clang-offload-*/ @intel/dpcpp-tools-reviewers
 ESIMD/ @intel/dpcpp-esimd-reviewers
 esimd/ @intel/dpcpp-esimd-reviewers
 sycl/include/sycl/ext/intel/experimental/esimd.hpp @intel/dpcpp-esimd-reviewers
-sycl/doc/extensions/ExplicitSIMD/ @intel/dpcpp-esimd-reviewers
+sycl/doc/extensions/experimental/sycl_ext_intel_esimd/ @intel/dpcpp-esimd-reviewers

.github/workflows/issue-release-workflow.yml

@@ -19,9 +19,12 @@ on:
     types:
       - created
       - edited
+  issues:
+    types:
+      - opened
 
 env:
-  COMMENT_BODY: ${{ github.event.comment.body }}
+  COMMENT_BODY: ${{ github.event.action == 'opened' && github.event.issue.body || github.event.comment.body  }}
 
 jobs:
   backport-commits:
@@ -30,7 +33,7 @@ jobs:
     if: >-
         (github.repository == 'llvm/llvm-project') &&
         !startswith(github.event.comment.body, '<!--IGNORE-->') &&
-        contains(github.event.comment.body, '/cherry-pick')
+        contains(github.event.action == 'opened' && github.event.issue.body || github.event.comment.body, '/cherry-pick')
     steps:
       - name: Fetch LLVM sources
         uses: actions/checkout@v2

.github/workflows/issue-subscriber.yml

@@ -18,9 +18,12 @@ jobs:
         pip install -r requirements.txt
 
     - name: Update watchers
+      # https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-an-intermediate-environment-variable
+      env:
+        LABEL_NAME: ${{ github.event.label.name }}
       run: |
         ./github-automation.py \
-          --token ${{ secrets.ISSUE_SUBSCRIBER_TOKEN }} \
+          --token '${{ secrets.ISSUE_SUBSCRIBER_TOKEN }}' \
           issue-subscriber \
-          --issue-number ${{ github.event.issue.number }} \
-          --label-name ${{ github.event.label.name }}
+          --issue-number '${{ github.event.issue.number }}' \
+          --label-name "$LABEL_NAME"

CONTRIBUTING.md

@@ -15,24 +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.
+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.
 
-**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.
+Every change should be accompanied with corresponding test modification (adding
+new test(s), extending, removing or modifying existing test(s)).
 
-**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/ABIPolicyGuide.md) for more information.
+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
@@ -47,110 +41,41 @@ see [ABI Policy Guide](sycl/doc/ABIPolicyGuide.md) for more 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
+#### Project-specific contribution guidelines
 
-Every product change should be accompanied with corresponding test modification
-(adding new test(s), extending, removing or modifying existing test(s)).
+- [Contribute to DPC++](/../sycl/sycl/doc/developer/ContributeToDPCPP.md)
 
-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.
+### Pull request
 
-    **General guidelines for adding DPC++ in-tree tests**:
-
-    - Use `sycl::` namespace instead of `cl::sycl::`
-
-    - Add a helpful comment describing what the test does at the beginning and
-    other comments throughout the test as necessary.
-
-    - 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 });
-    });
-    ```
-
-    **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).
@@ -159,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>

README.md

@@ -1,30 +1,86 @@
 # Intel Project for LLVM\* technology
 
-Intel staging area for llvm.org contribution. Home for Intel LLVM-based projects:
+This is the Intel staging area for llvm.org contributions and the home for
+Intel LLVM-based projects:
+
+- [oneAPI Data Parallel C++ compiler](#oneapi-data-parallel-c-compiler)
+- [Late-outline OpenMP and OpenMP Offload](#late-outline-openmp-and-openmp-offload)
 
 ## oneAPI Data Parallel C++ compiler
 
 [![](https://spec.oneapi.io/oneapi-logo-white-scaled.jpg)](https://www.oneapi.io/)
 
-See [sycl](https://github.com/intel/llvm/tree/sycl) branch and
-[DPC++ Documentation](https://intel.github.io/llvm-docs/).
-
 [![Linux Post Commit Checks](https://github.com/intel/llvm/workflows/Linux%20Post%20Commit%20Checks/badge.svg)](https://github.com/intel/llvm/actions?query=workflow%3A%22Linux+Post+Commit+Checks%22)
 [![Generate Doxygen documentation](https://github.com/intel/llvm/workflows/Generate%20Doxygen%20documentation/badge.svg)](https://github.com/intel/llvm/actions?query=workflow%3A%22Generate+Doxygen+documentation%22)
 
-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.
+The Data Parallel C++ or DPC++ is a LLVM-based compiler project that implements
+compiler and runtime support for the SYCL\* language. The project is hosted in
+the [sycl](/../../tree/sycl) branch and is synced with the tip of the LLVM
+upstream main branch on a regular basis (revisions delay is usually not more
+than 1-2 weeks). DPC++ compiler takes everything from LLVM upstream as is,
+however some modules of LLVM might be not included in the default project build
+configuration. Additional modules can be enabled by modifying build framework
+settings.
 
-## Late-outline OpenMP\* and OpenMP\* Offload
-See [openmp](https://github.com/intel/llvm/tree/openmp) branch.
+The DPC++ goal is to support the latest SYCL\* standard and work on that is in
+progress. DPC++ also implements a number of extensions to the SYCL\* standard,
+which can be found in the [sycl/doc/extensions](/../sycl/sycl/doc/extensions)
+directory.
 
-# License
+The main purpose of this project is open source collaboration on the DPC++
+compiler implementation in LLVM across a variety of architectures, prototyping
+compiler and runtime library solutions, designing future extensions, and
+conducting experiments. As the implementation becomes more mature, we try to
+upstream as much DPC++ support to LLVM main branch as possible. See
+[SYCL upstreaming working group notes](/../../wiki/SYCL-upstreaming-working-group-meeting-notes)
+for more details.
+
+Note that this project can be used as a technical foundation for some
+proprietary compiler products, which may leverage implementations from this open
+source project. One of the examples is
+[Intel(R) oneAPI DPC++ Compiler](https://www.intel.com/content/www/us/en/developer/tools/oneapi/dpc-compiler.html)
+Features parity between this project and downstream projects is not guaranteed.
+
+Project documentation is available at:
+[DPC++ Documentation](https://intel.github.io/llvm-docs/).
+
+### How to use DPC++
+
+#### Docker containers
+
+See available containers with pre-built/pre-installed DPC++ compiler at:
+[Containers](/../sycl/sycl/doc/developer/DockerBKMs.md#sycl-containers-overview)
 
-See [LICENSE.txt](sycl/LICENSE.TXT) for details.
+#### Releases
 
-# Contributing
+Daily builds of the sycl branch on Linux are available at
+[releases](/../../releases).
+A few times a year, we publish [Release Notes](/../sycl/sycl/ReleaseNotes.md) to
+highlight all important changes made in the project: features implemented and
+issues addressed. The corresponding builds can be found using
+[search](https://github.com/intel/llvm/releases?q=oneAPI+DPC%2B%2B+Compiler&expanded=true)
+in daily releases. None of the branches in the project are stable or rigorously
+tested for production quality control, so the quality of these releases is
+expected to be similar to the daily releases.
+
+#### Build from sources
+
+See [Get Started Guide](/../sycl/sycl/doc/GetStartedGuide.md).
+
+### Report a problem
+
+Submit an [issue](/../../issues) or initiate a [discussion](/../../discussions).
+
+### How to contribute to DPC++
+
+See [ContributeToDPCPP](/../sycl/sycl/doc/developer/ContributeToDPCPP.md).
+
+## Late-outline OpenMP\* and OpenMP\* Offload
+
+See [openmp](/../../tree/openmp) branch.
+
+# License
 
-See [CONTRIBUTING.md](CONTRIBUTING.md) for details.
+See [LICENSE](/../sycl/sycl/LICENSE.TXT) for details.
 
-*\*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>

bolt/include/bolt/Core/BinaryContext.h

@@ -211,7 +211,7 @@ class BinaryContext {
   std::map<unsigned, DwarfLineTable> DwarfLineTablesCUMap;
 
 public:
-  static std::unique_ptr<BinaryContext>
+  static Expected<std::unique_ptr<BinaryContext>>
   createBinaryContext(const ObjectFile *File, bool IsPIC,
                       std::unique_ptr<DWARFContext> DwCtx);
 

bolt/include/bolt/Core/MCPlusBuilder.h

@@ -74,9 +74,9 @@ class MCPlusBuilder {
   AllocatorIdTy MaxAllocatorId = 0;
 
   /// We encode Index and Value into a 64-bit immediate operand value.
-  static int64_t encodeAnnotationImm(unsigned Index, int64_t Value) {
-    assert(Index < 256 && "annotation index max value exceeded");
-    assert((Value == (Value << 8) >> 8) && "annotation value out of range");
+  static int64_t encodeAnnotationImm(uint8_t Index, int64_t Value) {
+    if (LLVM_UNLIKELY(Value != extractAnnotationValue(Value)))
+      report_fatal_error("annotation value out of range");
 
     Value &= 0xff'ffff'ffff'ffff;
     Value |= (int64_t)Index << 56;
@@ -85,14 +85,13 @@ class MCPlusBuilder {
   }
 
   /// Extract annotation index from immediate operand value.
-  static unsigned extractAnnotationIndex(int64_t ImmValue) {
+  static uint8_t extractAnnotationIndex(int64_t ImmValue) {
     return ImmValue >> 56;
   }
 
   /// Extract annotation value from immediate operand value.
   static int64_t extractAnnotationValue(int64_t ImmValue) {
-    ImmValue &= 0xff'ffff'ffff'ffff;
-    return (ImmValue << 8) >> 8;
+    return SignExtend64<56>(ImmValue & 0xff'ffff'ffff'ffffULL);
   }
 
   MCInst *getAnnotationInst(const MCInst &Inst) const {

bolt/include/bolt/Passes/ShrinkWrapping.h

@@ -308,8 +308,8 @@ class ShrinkWrapping {
   std::vector<MCInst *> BestSavePos;
 
   /// Pass stats
-  static uint64_t SpillsMovedRegularMode;
-  static uint64_t SpillsMovedPushPopMode;
+  static std::atomic_uint64_t SpillsMovedRegularMode;
+  static std::atomic_uint64_t SpillsMovedPushPopMode;
 
   Optional<unsigned> AnnotationIndex;