Comments (3)
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).
from spirv-llvm-translator.
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?
from spirv-llvm-translator.
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 than1.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.
from spirv-llvm-translator.
Related Issues (20)
- Build Failure in relation to the master of llvm
- Build is broken on LLVM 17 and some other branches HOT 2
- llvm_release_150 regression: FortranArrayNoType test fails HOT 4
- Is there no 18.0.0 HOT 2
- Missing SPIR-V 1.4 features/changes HOT 2
- llvm-as does not verify LLVM output from SPIR-V to LLVM translation (Overlapping tbaa.struct regions) HOT 2
- Indicies in SpecConstantOp PtrAccessChain of global variales are not adjusted for their actual type.
- Both GetElementPtrConstantExpr and GetElementPtrInst may represent access to a buildin variable HOT 1
- `ID '19' decorated with NoSignedWrap multiple times is not allowed.` HOT 1
- Translator incapable to generate TypeStruct EntryPoint parameters
- User defined/declared functions are wrongly identified as OpenCL builtins HOT 1
- Invalid OpenCL version and non-cpp source language lead to crash while generating device-dependent OpenCL binaries from a valid SPIR-V input HOT 9
- InvalidInstruction: Can't translate llvm instruction with LLVM 18 (working with 17) HOT 8
- spt file containing GlobalVariableHostAccessINTEL changes after -to-binary and then -to-text
- Drop llvm.compiler.used GV? HOT 1
- Add SPIR-V backend - SPIR-V Translator cross validation HOT 4
- SPV_EXT_relaxed_printf_string_address_space allows format from too many address spaces
- How to build LLVMSPIRVLib as a shared library on Windows? HOT 2
- Image validation in unit test
- Two days tyring to figure this out. HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spirv-llvm-translator.