following SPIRV Instructions serializaiton/deserialization are added
as well
OpFunction
OpFunctionParameter
OpFunctionEnd
OpReturn
PiperOrigin-RevId: 257869806
SPIR-V has a JSON grammar file that defines the syntax of SPIR-V
instructions. However, its lacks fine-grained constraints on
instruction operands; those information is only available as
natural language sentences in the SPIR-V spec, which also contains
the detailed documentation for each SPIR-V instruction.
This CL pulls information from both the JSON grammar and HTML
spec. It right now uses the former to deduce the arguments and
results (with coarse-grained constraints) and the latter for
documentation. In the future we can add the functionality to
match certain natural language sentences for more fine-grained
constraints, but right now the developer is expected to update
the generated op definition. This should serve as a nice
bootstrap step to save efforts.
PiperOrigin-RevId: 257821205
JSON spec into the SPIRBase.td file. This is done incrementally to
only import those opcodes that are needed, through use of the script
define_opcode.sh added.
PiperOrigin-RevId: 257517343
This saves us the excessive string conversions and comparisons in
verification and transformation and scopes them only to parsing
and printing, which are meant for I/O so string conversions should
be fine.
In order to do this, changed the custom assembly format of
spv.module regarding addressing model and memory model.
PiperOrigin-RevId: 256149856
Pointer types need to specify the storage class. We use the utility functions
generated from SPV_StorageClassAttr to parse and print the storage classes.
Also improved the case that no element type is provided for (runtime) array.
PiperOrigin-RevId: 252935599
This script parses the SPIR-V JSON grammar to extract operand kinds that
are enums and generate TableGen definitions for them.
Also added a shell script to point to the correct relative file location
to simplify command invocation.
--
PiperOrigin-RevId: 251041084
consistent and moving the using declarations over. Hopefully this is the last
truly massive patch in this refactoring.
This is step 21/n towards merging instructions and statements, NFC.
PiperOrigin-RevId: 227178245
1) affineint (as it is named) is not a type suitable for general computation (e.g. the multiply/adds in an integer matmul). It has undefined width and is undefined on overflow. They are used as the indices for forstmt because they are intended to be used as indexes inside the loop.
2) It can be used in both cfg and ml functions, and in cfg functions. As you mention, “symbols” are not affine, and we use affineint values for symbols.
3) Integers aren’t affine, the algorithms applied to them can be. :)
4) The only suitable use for affineint in MLIR is for indexes and dimension sizes (i.e. the bounds of those indexes).
PiperOrigin-RevId: 216057974
Mahesh Ravishankar