- introduce splat op in standard dialect (currently for int/float/index input
type, output type can be vector or statically shaped tensor)
- implement LLVM lowering (when result type is 1-d vector)
- add constant folding hook for it
- while on Ops.cpp, fix some stale names
Signed-off-by: Uday Bondhugula <uday@polymagelabs.com>
Closestensorflow/mlir#141
COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/141 from bondhugula:splat 48976a6aa0a75be6d91187db6418de989e03eb51
PiperOrigin-RevId: 270965304
Add a preprocess phase to rewrite parts of the input line that may be problematic with filecheck. This change adds preprocessing to escape '[[' bracket sequences, as these are used by FileCheck for variables.
PiperOrigin-RevId: 269648490
Certain enum classes in SPIR-V, like function/loop control and memory
access, are bitmasks. This CL introduces a BitEnumAttr to properly
model this and drive auto-generation of verification code and utility
functions. We still store the attribute using an 32-bit IntegerAttr
for minimal memory footprint and easy (de)serialization. But utility
conversion functions are adjusted to inspect each bit and generate
"|"-concatenated strings for the bits; vice versa.
Each such enum class has a "None" case that means no bit is set. We
need special handling for "None". Because of this, the logic is not
general anymore. So right now the definition is placed in the SPIR-V
dialect. If later this turns out to be useful for other dialects,
then we can see how to properly adjust it and move to OpBase.td.
Added tests for SPV_MemoryAccess to check and demonstrate.
PiperOrigin-RevId: 269350620
SPIR-V recently publishes v1.5, which brings a bunch of symbols
into core. So the suffix "KHR"/"EXT"/etc. is removed from the
symbols. We use a script to pull information from the spec
directly.
Also changed conversion and tests to use GLSL450 instead of
VulkanKHR memory model. GLSL450 is still the main memory model
supported by Vulkan shaders and it does not require extra
capability to enable.
PiperOrigin-RevId: 268992661
Use the existing SPV_LogicalOp specification to add the floating-point
comparison operations (both ordered and unordered versions).
To make it easier to import the op-definitions automatically modify
the dialect generation script to update the different .td files based
on whether the operation is an arithmetic op, logical op, etc. Also
allow specification of multiple opcodes with define_inst.sh.
Since this reuses the SPV_LogicalOp framework, no tests specific to
the floating point comparison ops are added with this CL.
PiperOrigin-RevId: 266561634
This CL just covers the op definition, its parsing, printing,
and verification. (De)serialization is to be implemented
in a subsequent CL.
PiperOrigin-RevId: 266431077
- 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
