SPIRV output of DPC++

[tneval]

I am trying to go through SYCL -> DPC++ -> SPIRV -> OpenCL.

My problem is that produced SPIRV does not seem to be very portable. More specifically, it uses some intel extension that my OpenCL implementation does not support.

; SPIR-V
; Version: 1.4
; Generator: Khronos LLVM/SPIR-V Translator; 14
; Bound: 138
; Schema: 0
               OpCapability Addresses
               OpCapability Linkage
               OpCapability Kernel
               OpCapability Int64
               OpCapability GenericPointer
               OpCapability Int8
               OpCapability OptNoneINTEL
               OpExtension "SPV_INTEL_optnone"

So my question is; is there a way to control SPIRV output such that for example some intel-specific extensions are disabled?

[AlexeySachkov]

Hi @Newsky7,

Yeah, we have raised a bar quite a bit for underlying backends and that is something we should consider improving (tagging @bashbaug and @gmlueck for awareness).

However, there should be a way for you to proceed forward. We have a hidden option in clang, which allows to pass arguments to the SPIR-V translator directly: -Xspirv-translator=<triple> <arg>, -Xspirv-translator <arg>. I'm not entirely sure how exactly it works, i.e. what does it do with "built-in" options to the translator which are generated by the compiler driver and I also don't remember how exactly the translator behaves when --spirv-ext option is passed several times. The path to do some experiments for you is to try and pass -Xspirv-translator --spirv-ext=-all to prevent the translator from emitting any extensions

[bashbaug]

I found an extension spec for SPV_INTEL_optnone in this repo, but it is not currently on the SPIR-V registry. Is that intended?

https://github.com/intel/llvm/blob/sycl/sycl/doc/design/spirv-extensions/SPV_INTEL_optnone.asciidoc

AFAICT this SPIR-V "function control" is intended to represent the LLVM "optnone" function attribute:

https://llvm.org/docs/LangRef.html#function-attributes

Do we generate this function attribute by default? If not, is our SPIR-V generator smart enough to only require the extension when the function attribute is present?

@Newsky7 I think it's great that you're trying to run SYCL applications via DPC++ on your OpenCL implementation. If you're able to say, which OpenCL implementation are you trying to run on? Thanks!

[bader]

I found an extension spec for SPV_INTEL_optnone in this repo, but it is not currently on the SPIR-V registry. Is that intended?

I don't think so, I'd like @MrSidims and @Fznamznon to confirm.

Do we generate this function attribute by default? If not, is our SPIR-V generator smart enough to only require the extension when the function attribute is present?

We do not emit this attribute by default and SPIR-V generator does not require the extension w/o it.
@Newsky7, I suppose you compile SYCL code with -O0 option. Am I right?

[MrSidims]

I don't think so, I'd like @MrSidims and @Fznamznon to confirm.

Not going into the details in public - but we now have a clearer process of pushing our extensions to public, it's a matter of time to upstream this extension.

[tneval]

@AlexeySachkov, Thanks for this information, I will look into it!

@bashbaug, I am attempting to make this work on PoCL. Oh, and just to clarify; I did not intend to say that I have my own OpenCL implementation, just using PoCL ;)

@bader, Yeah I tried compiling with -O0 and -O3 options.

[bader]

@Newsky7, do you see OpCapability OptNoneINTEL in the SPIR-V file compiled with -O3?

[tneval]

@Newsky7, do you see OpCapability OptNoneINTEL in the SPIR-V file compiled with -O3?

@bader, yeah it is still there.

[bader]

This sounds like a bug, but I can't reproduce it on my system. Could you provide a way to reproduce this, please?

[AlexeySachkov]

I think that presence of optnone attribute somewhere in a source code (maybe in our headers?) will generate this as well.

itt instrumentation could be one of the reasons why optnone is appearing, -fno-sycl-instrument-device-code is the flag to disable it.

[bader]

I see itt instrumentations in my code, but no OptNoneINTEL capability is required in SPIR-V file.

UPDATE: the hint from Alexey helped me to get reproduce the problem. I managed generate SPIR-V requiring OptNoneINTEL capability with -O3 and it indeed required for itt instrumentation functions.

[tneval]

I think that presence of optnone attribute somewhere in a source code (maybe in our headers?) will generate this as well.

itt instrumentation could be one of the reasons why optnone is appearing, -fno-sycl-instrument-device-code is the flag to disable it.

-fno-sycl-instrument-device-code indeed fixed my issue. Thanks a lot!