You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, lots of bits of rspirv are generated from the JSON grammar, this is to allow fast and correct updating and bulk feature addition. However, as rspirv grows more and more of this will need to be customised, some of these may be able to be upstreamed into the grammar file, some will not. The goal of this issue is to make sure that the cost of these customisations doesn't exceed the value of the autogen. If that does happen then the auto-generated code will be inlined and all updates will need to be provided manually.
Below is a list of all of the current customisations to auto-generated code, feel free to edit the list if you spot, or add, some more.
spirv.core.grammar.json: Branch instructions have their class renamed from Terminator to Branch (should be upstreamed)
spirv.core.grammar.json: OpPhi's third operand renamed from 'Variable, Parent, ...' to 'ValueLabelPairs' (could be upstreamed?)
OpPhi in general is treated uniquely
autogen/binary: LiteralInteger has special method name handling
autogen/binary: All possible pair kinds are hardcoded
autogen/binary: "IdResultType", "IdResult", "LiteralContextDependentNumber", "LiteralSpecConstantOpInteger" are all handled manually
autogen/binary: NaN has dodgy snake_casing rules
autogen/dr: IdResult treated separately
autogen/dr: OpReturn and OpReturnValue have special function names (as return is a keyword)
autogen/dr: LiteralString has different get_init_list handling
autogen/dr: Pair types treated separately again, in get_push_extras
autogen/dr: All number kinds hardcoded
autogen/dr: Pointer types filtered out in gen_dr_builder_types
autogen/header: NaN has special snake casing rules
autogen/header: Dim types have Dim prepended as types can't start with numbers
autogen/sr: Lots of operand types have special name and typing rules
I think it would be nice to avoid having an in-tree spirv.core.grammar.json as a first step. The modifications in the in-tree spirv.core.grammar.json mainly fall into two categories: assign categories to instructions so we can handle similar instructions in a batch using their category. I think this part is upstreamable. The other changes are mainly for adjusting the name so we can generate better parameter names in APIs. I don't think this part is upstreamable given that the names in the orignial JSON file are used to generate the spec. We can maintain a Rust list somewhere so we have a centralized place for the adjustment when generating names for instruction operands.
Currently, lots of bits of rspirv are generated from the JSON grammar, this is to allow fast and correct updating and bulk feature addition. However, as rspirv grows more and more of this will need to be customised, some of these may be able to be upstreamed into the grammar file, some will not. The goal of this issue is to make sure that the cost of these customisations doesn't exceed the value of the autogen. If that does happen then the auto-generated code will be inlined and all updates will need to be provided manually.
Below is a list of all of the current customisations to auto-generated code, feel free to edit the list if you spot, or add, some more.
spirv.core.grammar.json
: Branch instructions have their class renamed fromTerminator
toBranch
(should be upstreamed)spirv.core.grammar.json
:OpPhi
's third operand renamed from 'Variable, Parent, ...' to 'ValueLabelPairs' (could be upstreamed?)autogen/binary
:LiteralInteger
has special method name handlingautogen/binary
: All possible pair kinds are hardcodedautogen/binary
: "IdResultType", "IdResult", "LiteralContextDependentNumber", "LiteralSpecConstantOpInteger" are all handled manuallyautogen/binary
: NaN has dodgy snake_casing rulesautogen/dr
:IdResult
treated separatelyautogen/dr
:OpReturn
andOpReturnValue
have special function names (as return is a keyword)autogen/dr
:LiteralString
has differentget_init_list
handlingautogen/dr
: Pair types treated separately again, inget_push_extras
autogen/dr
: All number kinds hardcodedautogen/dr
: Pointer types filtered out ingen_dr_builder_types
autogen/header
: NaN has special snake casing rulesautogen/header
: Dim types have Dim prepended as types can't start with numbersautogen/sr
: Lots of operand types have special name and typing rulesautogen/sr
: Decoration ops treated completely separatelyautogen/sr
:gen_sr_code_from_instruction_grammar
skips constantsautogen/sr
:gen_sr_code_from_instruction_grammar
has special casing for types, function ops, branches, terminators and phi instructionsautogen/util
: Literal numbers get unique operand kindautogen/util
: underlying type for pairs, literals and ids are all specialautogen/util
: Parameter name forIdResultType
hardcodedThe text was updated successfully, but these errors were encountered: