[SYCL] Always generate specialization constants buffer

[AGindinson]

The discrepancy of kernel signatures between SPIR-V images (for which
SYCL2020 spec constants are supported natively) and AOT-compiled
images (which actually require the buffer to emulate SYCL2020 spec
constants) has blocked the multi-target compilation & execution when
the feature is used. Since the integration header was common for both
targets, RT attempted to set the specialization constants buffer argument
for the native target.

Align the kernel signatures by generating a (nullified) buffer for the SPIR-V
target as well and make sure it is handled correctly by the DPC++ RT.

Tested in intel/llvm-test-suite#584.

Signed-off-by: Artem Gindinson [email protected]

[AGindinson]

/verify with intel/llvm-test-suite#584

[AGindinson]

/verify with intel/llvm-test-suite#584

[AGindinson]

CUDA reduction failures are the known unrelated ones.

[elizabethandrews]

So the only difference in how kernel_handler argument is now handled for native vs non-native support is in how it is initialized - i.e. the former uses default initialization while latter results in call to __init. Did I get that right?

[AGindinson]

So the only difference in how kernel_handler argument is now handled for native vs non-native support is in how it is initialized - i.e. the former uses default initialization while latter results in call to __init. Did I get that right?

This is what I've attempted, yes. Since the RT adjustments allow to handle the default-initialized (null) buffer, I've thought this would be sufficient on the FE part.

[premanandrao]

So the only difference in how kernel_handler argument is now handled for native vs non-native support is in how it is initialized - i.e. the former uses default initialization while latter results in call to __init. Did I get that right?

Thanks for asking this @elizabethandrews, it helped. :-)