handling extensions and spirv versions

[airlied]

I haven't dug too deeply on this yet, but I was wondering what would the plan be for handling SPIR-V extensions.

Say we added a new CL SPIR-V extension for a new instruction and I wanted to generate it or we wanted to generate SPIR-V compatible with spirv 1.1 or 1.3 etc.

wrt triples would this need to be encoded in the triple?

Apologies if this is a bit vague :-)

[AnastasiaStulova]

I would also like to understand general architecture and strategy i.e. currently Clang accepts all vendor extensions under SPIR. Does it mean we will require translator to support all too? Or should it at least give an error if it encounter unknown extension?

[AlexeySachkov]

I would also like to understand general architecture and strategy i.e. currently Clang accepts all vendor extensions under SPIR. Does it mean we will require translator to support all too? Or should it at least give an error if it encounter unknown extension?

I think we cannot accept all accept vendor extensions - we can only support vendor extensions that are known to translator: in general, vendor extension might introduce different kind of entities in LLVM IR which cannot be translated as-is to SPIR-V: for example, new types. So, I would vote for emitting errors if unknown extension was encountered.

Selecting supported extensions is tightly related to selecting SPIR-V version, because there are extensions that were included into core functionality by the newer spec versions.

My vision of this mechanism is based on the following ideas:

• There should be an option to specify certain SPIR-V version that must be generated by the translator.
• There should be an option to restrict max allowed SPIR-V version: this is pretty usable if you don't care about the certain SPIR-V version, but you consumer is not able to support anything newer than 1.2, for example
• There should be an option to allow or disallow using of certain SPIR-V extensions by the translator during generation step
• There should be an option to emit errors during consumption step if SPIR-V contains disallowed extension - it might be useful for consumers based on this project: rather than checking generated LLVM IR to understand if it contains something unsupported or not, consumer can instruct translator to reject such SPIR-V files at all.

SPIR-V version

If no additional options was passed to translator - what should we do? Possible options:

• Emit the highest possible value
• Emit the lowest possible value based on input file - current behavor

New command line options:

-spirv-version=1.2 flag allows you to set target SPIR-V version. Affects SPIR-V generation step. If translator encounters something that cannot be represented by the target SPIR-V version, it may try to emulate it (example in #35), skip translation of corresponding LLVM IR entity (skip dereferencable LLVM IR attribute if -spriv-version=1.0) or emit error.

-max-spirv-version=1.2 flag allows you to set maximal allowed SPIR-V version. Affects SPIR-V generation step. If translator encounters something that cannot be represented by the range of allowed SPIR-V versions, it may try to emulate it (example in #35) or emit error.

SPIR-V extensions

If no additional options was specified:

• During SPIR-V generation, all extensions are disabled by default. List of allowed instructions is defined by target SPIR-V version. If translator encounters something that cannot be represented without particular extension it may try to emulate it (I don't know good examples), skip generation of such entity (translator may skip handling of nsw/nuw LLVM IR flags if target SPIR-V version is lower than 1.4) or emit error.
• During SPIR-V consumption, all known extensions are enabled by default: it means that translator will generate LLVM IR even if input SPIR-V file uses some known extensions. If input SPIR-V file uses unknown extension, translator can emit error.

-spirv-ext=<value1>,<value2>,<value3> flag allows you to enable/disable translation of specific SPIR-V extensions. Affects both SPIR-V generation and consumption steps. Possible values and behavior during generation step:

• SPV_%extension_name% - allows translator to emit instructions from the specified extension. If during generation translator encounters something that can be represented with this extension, it uses it rather than trying to emulate or skip an LLVM IR entity. If enabled extension is unknown to translator, it emits error.

For SPIR-V consumption step -spirv-ext option might be used to specify extension that supported by the consumer: If during consumption step translator sees that input SPIR-V file uses extension that wasn't passed via -spirv-ext option, translator emits error.

[AlexeySachkov]

I guess this can be considered as implemented for now and closed - at least basic infrastructure has landed. It provides possibility to specify max allowed SPIR-V version and allows to explicitly enable/disable SPIR-V extensions. New functionality covers both llvm-spirv tool and the translator API.

Documentation can be found here.

I think I will open another one issue as follow-up from #244: add possibility to specify minimum allowed SPIR-V version: @tremmelg pointed out that there are use-cases for such option:

some features have been removed. For example, OpAtomicCompareExchangeWeak is missing after SPIR-V 1.3 (https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#_a_id_atomic_a_atomic_instructions).