[SYCL] VS2026 support #21990
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| // RUN: %clang_cc1 -triple spir64-unknown-unknown -aux-triple x86_64-pc-windows-msvc \ | ||
| // RUN: -fsycl-is-device -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s | ||
|
|
||
| // When SYCL device code is compiled with a Windows-MSVC host, the device | ||
| // target (spir64) defines _M_X64 so that MSVC STL headers take the x86 | ||
| // intrinsics path. The device target feature set must correspondingly carry | ||
| // sse/sse2 so that function-level __target__ attributes (e.g. VS2026 | ||
| // <complex>'s [[gnu::target("fma")]] on _Sqr_error_x86_x64_fma) don't strip | ||
| // the baseline, which would break intrinsic calls like _mm_set_sd / _mm_store_sd. | ||
|
Comment on lines
+4
to
+9
Contributor
There was a problem hiding this comment. I don't understand this either. Why would
Contributor
Author
There was a problem hiding this comment. Correct. The
Contributor
There was a problem hiding this comment. Thanks, I wasn't aware of the Pondering, I wonder how much success we might have in trying to convince Microsoft to accept a series of PRs that add checks for |
||
|
|
||
| #include "Inputs/sycl.hpp" | ||
|
|
||
| int main() { | ||
| sycl::queue q; | ||
| q.submit([&](sycl::handler &h) { h.single_task<class TestK>([=] {}); }); | ||
| return 0; | ||
| } | ||
|
|
||
| // CHECK: spir_kernel void @{{.*}}TestK{{.*}}() [[ATTRS:#[0-9]+]] | ||
| // CHECK: attributes [[ATTRS]] = {{.*}}"target-features"="+sse,+sse2" | ||
|
Contributor
There was a problem hiding this comment. I'm surprised we don't have an existing test to validate |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,49 @@ | ||
| //==---- __msvc_bit_utils.hpp wrapper around MSVC STL ---------------------==// | ||
| // | ||
| // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. | ||
| // See https://llvm.org/LICENSE.txt for license information. | ||
| // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
| // | ||
| //===----------------------------------------------------------------------===// | ||
|
|
||
| #pragma once | ||
|
|
||
| // VS2026 MSVC STL's <__msvc_bit_utils.hpp> declares `__isa_available` (a | ||
| // runtime CPU-feature global) and other STL headers (<bit>, <vector>, | ||
| // <numeric>, <bitset>, <complex>, <__msvc_int128.hpp>) include this header | ||
| // transitively. SYCL device code cannot access host runtime globals, so | ||
| // provide a device-side definition before the real header is included. | ||
| // | ||
| // The VALUE of this variable only steers the STL's runtime feature dispatch | ||
| // — both branches compile either way. We pick __ISA_AVAILABLE_X86 (== 0, | ||
| // the baseline in <isa_availability.h>), which matches a spir64 device's | ||
| // reality (no x86 ISA), and selects the STL's scalar fallback paths if the | ||
| // dispatches are ever reached. | ||
| // | ||
| // Mirror the source structure of MSVC STL's __msvc_bit_utils.hpp, which | ||
| // declares the symbol inside `namespace std { extern "C" { ... } }`. The | ||
| // `extern "C"` makes namespace placement linkage-neutral, but matching the | ||
| // MSVC source layout keeps this wrapper visually aligned with what it shadows. | ||
| #if defined(__SYCL_DEVICE_ONLY__) && defined(_MSC_VER) | ||
| namespace std { | ||
| extern "C" { | ||
| int __isa_available __attribute__((sycl_global_var)) | ||
| __attribute__((weak)) = 0; | ||
| } | ||
| } // namespace std | ||
| #endif // defined(__SYCL_DEVICE_ONLY__) && defined(_MSC_VER) | ||
|
|
||
| // Include real STL <__msvc_bit_utils.hpp> header - the next one from the | ||
| // include search directories. | ||
| #if defined(__has_include_next) | ||
| // GCC/clang support go through this path. | ||
| #include_next <__msvc_bit_utils.hpp> | ||
| #else | ||
| // MSVC doesn't support "#include_next", so we have to be creative. | ||
| // Our header is located in "stl_wrappers/__msvc_bit_utils.hpp" so it won't be | ||
| // picked by the following include. MSVC's installation, on the other hand, | ||
| // has the layout where the following would result in the | ||
| // <__msvc_bit_utils.hpp> we want. This is obviously hacky, but the best we | ||
| // can do... | ||
| #include <../include/__msvc_bit_utils.hpp> | ||
| #endif |
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.
This doesn't make sense to me. Why would we want to claim SSE and SSE2 availability for a target for which those are not relevant?
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.
It is confusing.
The
_M_X64macro is already defined for this target, which causes MSVC STL headers to take the x86 intrinsics path. ( yay! )VS2026's
<complex>introduces inline functions like_Sqr_error_x86_x64_fmaannotated[[__gnu__::__target__("fma")]], whose bodies call_mm_set_sd/_mm_store_sd. The target attribute layers fma on top of the existing baseline, it doesn't replace it, so if the baseline lacks sse/sse2, those mm* builtins fail their feature-compatibility check at parse time, even though the function is never called from device code.So we add SSE/SSE2 just to get past that check and to get things move forward again.
To my mind, since this target already claims
_M_X64then it's really a matter of being consistent. In for a penny...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.
I see, thanks for the detailed explanation.