* Validate enums have a sensible versions and are visible
Add version field for each eumerant.
For capabilities and instructions introduced by an extension (its
first version is "None"):
- the capability should be guarded by an extension
- the instruction should be guarded by a capability.
Other enums are presumed guarded transitiviely by use as an operand
to an instruction or another operand.
Fixes: #278, #368
* Fix capability logic, and check more cases
For capabilities, only check for lack of an extension.
If capability X lists capabilities Y and Z, those are not guards *for*
X, but rather when X is enabled it also implicitly enables Y and Z.
Also, an instruction that is *not* in a core SPIR-V version
must not be directly enabled by *both* and extension and a capability.
There are 78 existing cases that break this rule, so grandparent them
in with an allow-list.
* Add "version": "None" to enums added for a recent extension
Add it for the HostAccessQualifier enums from
SPV_INTEL_global_variable_host_access
Generate the overloaded C++11 operators as constexpr instead of inline.
constexpr implies inline but makes it possible to use the operators in
constexpr functions.
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
- Run on Linux, macOS and Windows
- Check that the headers install works
- Check the example can be built
- Check the header generation tool can be built
- Generate headers and check they match the committed files
- Mention the requirement to install the header generation tool in README
Change-Id: I8385b3931064ad677d7aa49b2514cea9b4602168
Signed-off-by: Kevin Petit <kevin.petit@arm.com>
In the grammar, enforce ordering rules:
- Instructions must appear in order of their opcode
- Non-instructions: each successive enumerant within a single kind must
appear in order
- Reorder enumerants Subgroup*MaskKHR enums to satisfy the rule.
This is a cosmetic change for the benefit of generating the SPIR-V spec.
It reorders the "FP Denorm Mode" and "FP Operation Mode" so they are
the last sections in chapter 3 before the instruction listing.
They become 3.37 and 3.38. The idea is to preserve the section numbering
for earlier sections. For example, keep 3.31 as the Capability section.
* Add JSON grammars for extened instruction sets
Add AMD extended instruction sets
Add DebugInfo
Add OpenCL.DebugInfo.100
* Add script to generate C headers from extinst grammar
This is cloned then adapted from the same-named script in SPIRV-Tools
(contributed under same authorship but different copyright).
Invoke the script as part of the overall header generation script.
* Add generated C header for extended instruction sets
Add for DebugInfo and OpenCLDebugInfo
Add for AMD vendor extended instruction sets
* Update the README for extinst header generation
* Fix header include guard to match directory structure
* Ensure generated header ends in newline
* Fix typo in file reference
* Fix name of AMD_shader_explicit_vertex_parameter.h
* Avoid duplicate generation
* Split Revision and Version enum values by newlines
Per code review request
* Convert C header generator driver to Python3
* Fix README for Python3 for extinst header generation
* Use 4-space in generated headers, consistently
Each instruction belongs to exactly one instruction class.
@exclude will put in the headers, but not in the specification.
Reserved is for instructions that are both to be reserved in the
specification and not yet put into another printing class.
(It is okay to establish a printing class for a reserved instruction.)
