- some of it has been adapted from LLVM's vim utils
Signed-off-by: Uday Bondhugula <uday@polymagelabs.com>
Closestensorflow/mlir#90
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/90 from bondhugula:vim 22b1c958818c4b09de0ec8e1d7a4893171a03dbf
PiperOrigin-RevId: 266071752
Generate the EnumAttr to represent BuiltIns in SPIR-V dialect. The
builtIn can be specified as a StringAttr with value being the
name of the builtin. Extend Decoration (de)serialization to handle
BuiltIns.
Also fix an error in the SPIR-V dialect generator script.
PiperOrigin-RevId: 263596624
This script is a utility to add FileCheck patterns to an mlir file. The script will heuristically insert CHECK/CHECK-LABEL commands for each line within the file. By default this script will also try to insert string substitution blocks for all SSA value names. The script is designed to make adding checks to a test case fast, it is *not* designed to be authoritative about what constitutes a good test!
Note: Some cases may not be handled well, e.g. operands to operations with regions, but this script is only intended to be a starting point.
Example usage:
$ generate-test-checks.py foo.mlir
$ mlir-opt foo.mlir -transformation | generate-test-checks.py
module {
func @fold_extract_element(%arg0: index) -> (f32, f16, f16, i32) {
%cst = constant 4.500000e+00 : f32
%cst_0 = constant -2.000000e+00 : f16
%cst_1 = constant 0.000000e+00 : f16
%c64_i32 = constant 64 : i32
return %cst, %cst_0, %cst_1, %c64_i32 : f32, f16, f16, i32
}
}
// CHECK-LABEL: func @fold_extract_element(
// CHECK-SAME: [[VAL_0:%.*]]: index) -> (f32, f16, f16, i32) {
// CHECK: [[VAL_1:%.*]] = constant 4.500000e+00 : f32
// CHECK: [[VAL_2:%.*]] = constant -2.000000e+00 : f16
// CHECK: [[VAL_3:%.*]] = constant 0.000000e+00 : f16
// CHECK: [[VAL_4:%.*]] = constant 64 : i32
// CHECK: return [[VAL_1]], [[VAL_2]], [[VAL_3]], [[VAL_4]] : f32, f16, f16, i32
// CHECK: }
PiperOrigin-RevId: 263242983
Basic* grammar to start of with, this doesn't handle custom ops and doesn't
handle ops with regions. But useful enough to make reading the .mlir files
easier.
Followed the approach used for emacs & vim and placed in separate directory
under utils.
* I got a little bit carried away trying to handle attributes and tried to do some custom op printing handling, but finally abandoned it. Also first time writing a textmate grammar so I assume a lot can be improved :)
PiperOrigin-RevId: 262985490
All non-argument attributes specified for an operation are treated as
decorations on the result value and (de)serialized using OpDecorate
instruction. An error is generated if an attribute is not an argument,
and the name doesn't correspond to a Decoration enum. Name of the
attributes that represent decoerations are to be the snake-case-ified
version of the Decoration name.
Add utility methods to convert to snake-case and camel-case.
PiperOrigin-RevId: 260792638
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
Uday Bondhugula