-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SYCLomatic] Fix the 1119 daily pulldown conflict #2496
Merged
zhimingwang36
merged 3,252 commits into
oneapi-src:SYCLomatic
from
ShengchenJ:1119_pulldown
Nov 21, 2024
Merged
[SYCLomatic] Fix the 1119 daily pulldown conflict #2496
zhimingwang36
merged 3,252 commits into
oneapi-src:SYCLomatic
from
ShengchenJ:1119_pulldown
Nov 21, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add missing semantic checks for the Workshare construct: OpenMP 5.2: 11.4 Workshare Construct - The construct must not contain any user-defined function calls unless either the function is pure and elemental or the function call is contained inside a parallel construct that is nested inside the workshare construct. (Flang-new used to check only the elemental function, but now it needs to be an impure elemental function) - At most one NoWait clause can appear in the Workshare construct. - Add tests for the same.
- At most one Collapse clause in SIMD construct - A DO loop must follow the SIMD directive
Add missing semantic check for the SAFELEN clause in the SIMD Order construct
This slightly improves the printing of VPInstructions. NFC except debug output.
…ing::hasFP()` (#106014) Some targets (e.g. PPC and Hexagon) already did this. I think it's best to do this consistently so that frontend authors don't run into inconsistent results when they emit `naked` functions. For example, in Zig, we had to change our emit code to also set `frame-pointer=none` to get reliable results across targets. Note: I don't have commit access.
In #99726, `-fptrauth-type-info-vtable-pointer-discrimination` was introduced, which is intended to enable type and address discrimination for type_info vtable pointers. However, some codegen logic for actually enabling address discrimination was missing. This patch addresses the issue. Fixes #101716
This is implementation is based on what the X86 target does but emitting the instructions that GCC emits for rv64. --------- Co-authored-by: Pengcheng Wang <[email protected]>
This patch adds the `ilogb` libcall. Constant folding will be handled in subsequent patches.
This issue is from llvm/llvm-project#77668. I encountered a build issue because it used Unicode. When I built MLIR on Windows with Visual Studio 2022, I faced a build failure. --------- Co-authored-by: Harrison Hao <[email protected]>
…the builtins not in Zve64*. (#112827) Fixes: llvm/llvm-project#109694
…101) Rewrite the AST matchers for slightly more composability. Furthermore, check that the `starts_with` and `ends_with` functions return a `bool`. There is one behavioral change, in that the methods of a class (and transitive classes) are searched once for a matching `starts_with`/`ends_with` function, picking the first it can find. Previously, the matchers would try to find `starts_with`, then `startsWith`, and finally, `startswith`. Now, the first of the three that is encountered will be the matched method. --------- Co-authored-by: Nicolas van Kempen <[email protected]>
With opaque pointers, the only purpose of the cast here is to cast between address spaces, similar to the 4-argument case below.
This enables the assertion introduced in llvm/llvm-project#106524, which checks that the value passed to the APInt constructor is indeed a valid N-bit signed or unsigned integer. Places that previously violated the assertion were updated in advance, e.g. in llvm/llvm-project#80309. It is possible to opt-out of the check and restore the previous behavior by setting implicitTrunc=true.
…(#112770) getElementType() was missing from Sequence and Vector types. Did a replace of the obvious places getEleTy() was used for these two types and updated to use this name instead. Co-authored-by: Scott Manley <[email protected]>
…ow in the frontend (#110061) This patch introduces the options for integer overflow flags into Flang. The behavior is similar to that of Clang.
This is what the current interpreter does as well.
We use the term "masking map" throughout the Linalg vectorization logic, but we don't really define what it is and how it differs from Linalg indexing maps. This PR clarifies the differnces, makes sure that the new terminology is used consistenty and improves code re-use.
Reverting because this is causing failures with MSan: https://lab.llvm.org/buildbot/#/builders/169/builds/4378 This reverts commit e1f8f84.
This patch adds scalable tuple types vectors for MFloat_8 type, according to the ACLE[1]. [1] https://github.com/ARM-software/acle.git
…st full (#112552) Zero diff in behavior.
Before using a constexpr variable that is not properly initialized check that it is valid. Fixes llvm/llvm-project#109095 Fixes llvm/llvm-project#112516
Always require functions to be larger than MinFunctionSize when SpecializeLiteralConstant is enabled, and increase MinFunctionSize to 500, to prevent excessive triggering of specialisations on small functions.
This patch fixes an off-by-one error in `mlir::getReassociationIndicesForCollapse()` that occurs when the last two dims of the source tensor satisfy the while loop. This would cause an assertion failure due to out-of-bounds-access, which is now fixed.
Scheduled igc dev drivers uplift --------- Signed-off-by: Sarnie, Nick <[email protected]> Co-authored-by: GitHub Actions <[email protected]> Co-authored-by: Jinsong Ji <[email protected]> Co-authored-by: Zhang, Yixing <[email protected]> Co-authored-by: Sarnie, Nick <[email protected]>
… in sycl-devops-pr" (#16092) Reverts intel/llvm#16079 This is cancelling jobs in unexpected ways, I need to debug it and fix the problem.
We can figure it out from the `sycl-ls` output. Confirmed working [here](https://github.com/intel/llvm/actions/runs/11841045635/job/32998817316?pr=16071) Closes: intel/llvm#16057 --------- Signed-off-by: Sarnie, Nick <[email protected]>
Mimics `clang::driver::tools::SYCL::getDeviceLibraries` assuming a SPIR-V target (= no AoT, no third-party GPUs, no native CPU). Same as for the compilation step, warning/error reporting is still rudimentary and will be improved in a future PR. --------- Signed-off-by: Julian Oppermann <[email protected]>
Initialized `urExternalSemaphore` to appease our Coverity overlords.
…#16003) Implement the changes made to the work group memory spec in this PR: intel/llvm#15933. Essentially, the default constructor is removed from the spec and instead a constructor that takes an indeterminate argument is made available in order to emphasize that any operation on such a work group memory object is undefined behavior except for assigning to it another work group memory object. Because the frontend needs special types to have a default constructor, we make it private instead and when its time for the frontend to call it, simply override the access specifier temporarily.
Dynamic linking was already supported in the old offloading model, so bring the support to the new offloading model.
…6066) Signed-off-by: jinge90 <[email protected]> Co-authored-by: Michael Toguchi <[email protected]>
The submit method on queue has caused multiple divergences throughout its lifetime, when additional information was required for new functionality. However, that design means an exponential growth in functions every time a new optional argument is needed. To battle this, this patch adds a new pimpl class with the optional submission info, which will only be initialized if needed. This boils the submit function paths down to one with event and one without. --------- Signed-off-by: Larsen, Steffen <[email protected]>
This patch is a collection of various cleanups made in public headers: - Cleaned up many unnecessary includes. It doesn't change total amount of header files we use in total by `sycl.hpp`, but makes our code cleaner - Made it so there are no headers (except for `backend/%backend_name%.hpp`) depend on `backend.hpp` and it is (almost) only included by `sycl.hpp`, so that we can make it an opt-in header - Removed `types.hpp` in favor of direct use of `vector.hpp` - Added missing includes and forward-declarations to places where we relied on implicit includes - Moved certain helper function declarations/definitions to better places (common utils to utils headers, library-only declarations to library headers, etc.)
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Pre-commit MR for: oneapi-src/unified-runtime#2222 --------- Co-authored-by: Callum Fare <[email protected]>
New `merge_properties` can work on property lists containing run-time properties as long as their keys don't conflict. That functionality isn't used anywhere as of now though, hence `NFC` tag.
Scheduled igc dev drivers uplift Co-authored-by: GitHub Actions <[email protected]> Co-authored-by: Nick Sarnie <[email protected]>
Fixes: CMPLRLLVM-63157 **Problem** Consider the following case: ``` clang++ -fsycl -c testFile.cpp -o obj1.o clang++ -fsycl -c testFile2.cpp -o obj2.o -fsycl-instrument-device-code clang++ -fsycl obj1.o obj2.o -o test.exe // test.exe fails with: JIT session error: Symbols not found: [ __itt_offload_wi_finish_wrapper, __itt_offload_wi_start_wrapper ] ``` This issue was observed while using MKL static libraries built with `-fsycl-instrument-device-code` with the latest compiler that does not link ITT annotations by default. With this change, we link in ITT libraries by default to stays ABI compliant with the previous release. During device code linking, if the device code is not instrumented with ITT annotations, this library will be omitted. Note that, even with this change, we are not instrumenting device code with ITT annotations by default.
…to UNSUPPORTED (#16098) XPASSing rarely like [here](https://github.com/intel/llvm/actions/runs/11859980629/job/33054700795). I updated the GH issue. Signed-off-by: Sarnie, Nick <[email protected]>
…#16005) For free function kernels support clang forward declares the kernel itself as well as its parameter types. In case a free function kernel has a parameter that is templated and has a default template argument, all template arguments including arguments that match default arguments must be printed in kernel's forward declarations, for example ``` template <typename T, typename = int> struct Arg { T val; }; // For the kernel SYCL_EXT_ONEAPI_FUNCTION_PROPERTY( (ext::oneapi::experimental::nd_range_kernel<1>)) void foo(Arg<int> arg) { arg.val = 42; } // Integration header must contain void foo(Arg<int, int> arg); ``` Unfortunately, even though integration header emission already has extensive support for forward declarations priting, some modifications to clang's type printing are still required, since neither of existing PrintingPolicy flags help to reach the correct result. Using `SuppressDefaultTemplateArgs = true` doesn't help without printing canonical types, printing canonical types for the case like ``` template <typename T> SYCL_EXT_ONEAPI_FUNCTION_PROPERTY( (ext::oneapi::experimental::nd_range_kernel<1>)) void foo(Arg<T> arg) { arg.val = 42; } // Printing canonical types is causing the following integration header template <typename T> void foo(Arg<type-parameter-0-0, int> arg); ``` Using `SkipCanonicalizationOfTemplateTypeParms` field of printing policy doesn't help here since at the one point where it is checked we take canonical type of `Arg`, not its parameters and it will contain template argument types in canonical type after that.
Signed-off-by: Chen, Sheng S <[email protected]>
Signed-off-by: Chen, Sheng S <[email protected]>
Signed-off-by: Chen, Sheng S <[email protected]>
Signed-off-by: Chen, Sheng S <[email protected]>
tomflinda
approved these changes
Nov 20, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
zhiweij1
approved these changes
Nov 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.