[SYCL] Enable SPV_INTEL_fpga_invocation_pipelining_attributes extension

[MrSidims]

Signed-off-by: Dmitry Sidorov dmitry.sidorov@intel.com

[MrSidims]

There is actually a gap in our design of how we enable SPIR-V extensions. I'm 100%, that Intel GPU doesn't support most of Intel FPGA extensions, but that issue is going to be addressed later.

[AlexeySachkov]

If SPIR-V extension can only be triggered by corresponding DPC++ feature and we are clear in our documentation/intent that it is not supported on GPU, it should be fine

[MrSidims]

From the test failure:

Unknown extension 'SPV_INTEL_fpga_invocation_pipelining_attributes'

Indeed we need a pull-down first.

[bader]

I converted this pull request to a draft to avoid unintentional merge.

[keryell]

I am curious about what it means for an FPGA attribute not to be supported on GPU or CPU or...
What happens if they are just ignored, like any other attribute?
At the end it would be nice to have a SYCL program just to work on any target and have functionality portability.

[AGindinson]

I am curious about what it means for an FPGA attribute not to be supported on GPU or CPU or...
What happens if they are just ignored, like any other attribute?
At the end it would be nice to have a SYCL program just to work on any target and have functionality portability.

@keryell, if I understand correctly, the reference here is made to this comment thread about the fact that we enable a whole set of SPIR-V extensions for any target regardless of whether these extensions are supported by the underlying device runtimes. In this light, "ignoring" unknown SPIR-V capabilities is simply not how the device runtimes are currently taught to operate - and changing their behavior is not something we could do on the SYCL level. If LLVM BC and not SPIR-V was used as the interface between the FE and device backends, metadata-based attributes (i.e. most of the attributes) could truly be ignored by "irrelevant" runtimes. But the latter is an unrealistic architectural change with too many drawbacks.

We could, however, search for ways to disable FPGA-specific extensions for non-FPGA targets within the compiler driver, thus providing source portability of the functionality (if not runtime portability). At least this is how I've parsed @MrSidims's comment.

Also, it is often the case that users employing target-specific attributes like "FPGA pipelining" do not require their sources to be instantly portable from the chosen target and/or rely on the preprocessor to define different code paths for, say, FPGA and CPU. Overall, the concerns about some compiled device objects with target-tuned code not being executable on other targets don't seem to be severe for DPC++ users - unless, of course, I'm missing some data that shows otherwise.

[keryell]

At least just ignoring the FPGA features either in Clang or in the SYCL runtime is an easy.
I am claiming everywhere that a super cool feature of SYCL is that it allows to emulate FPGA code on GPU in a super-fast way compared to CPU or RTL simulation, so I would be sad this is not possible! :-)
What happens in the GPU SPIR-V consumer if the SPIR-V has FPGA extensions with no semantic changed could be allowed too.
But probably filtering them out earlier is clearer and some conditional warnings can be optionally emitted.

[MrSidims]

I am claiming everywhere that a super cool feature of SYCL is that it allows to emulate FPGA code on GPU in a super-fast way compared to CPU or RTL simulation, so I would be sad this is not possible! :-)

(if only we could emulate DPCPP pipes on GPU (well, we actually could, but it's not working right now) :) )
We still can do that, most of these extensions are added to translate a certain LLVM metadata to SPIR-V. And whilst metadata can be easily ignored and removed from the IR module it's not always the case for SPIR-V: we indeed can safely remove decorations, but not instructions. So it would be a bit hard to support FPGA SPIR-V extensions in non-FPGA SPIR-V-centric devices' backends, and also not every FPGA attribute can be used to optimize IR for non-FPGA targets. The fact that if an extension is disabled in the driver doesn't mean, that the translator will emit an error - instead it will change translation flow and don't generate IR patterns appropriate for the extension.

There are also extensions (for now it's the only SPV_INTEL_usm_storage_classes) that can't be just ignored as it adds translation of not-common OpenCL address spaces. And it seems to be reasonable to deal with it in the 'middle-end' instead of different devices' backends.