Commit Graph

34 Commits

Author SHA1 Message Date
Chris Lattner 456ad6a8e0 Standardize naming of statements -> instructions, revisting the code base to be
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
2019-03-29 14:44:30 -07:00
Chris Lattner 315a466aed Rename BasicBlock and StmtBlock to Block, and make a pass cleaning it up. I did not make an effort to rename all of the 'bb' names in the codebase, since they are still correct and any specific missed once can be fixed up on demand.
The last major renaming is Statement -> Instruction, which is why Statement and
Stmt still appears in various places.

This is step 19/n towards merging instructions and statements, NFC.

PiperOrigin-RevId: 227163082
2019-03-29 14:43:58 -07:00
Chris Lattner 69d9e990fa Eliminate the using decls for MLFunction and CFGFunction standardizing on
Function.

This is step 18/n towards merging instructions and statements, NFC.

PiperOrigin-RevId: 227139399
2019-03-29 14:43:13 -07:00
Chris Lattner 5187cfcf03 Merge Operation into OperationInst and standardize nomenclature around
OperationInst.  This is a big mechanical patch.

This is step 16/n towards merging instructions and statements, NFC.

PiperOrigin-RevId: 227093712
2019-03-29 14:42:23 -07:00
Alex Zinenko 51c8a095a3 Materialize vector_type_cast operation in the SuperVector dialect
This operation is produced and used by the super-vectorization passes and has
been emitted as an abstract unregistered operation until now.  For end-to-end
testing purposes, it has to be eventually lowered to LLVM IR.  Matching
abstract operation by name goes into the opposite direction of the generic
lowering approach that is expected to be used for LLVM IR lowering in the
future.  Register vector_type_cast operation as a part of the SuperVector
dialect.

Arguably, this operation is a special case of the `view` operation from the
Standard dialect.  The semantics of `view` is not fully specified at this point
so it is safer to rely on a custom operation.  Additionally, using a custom
operation may help to achieve clear dialect separation.

PiperOrigin-RevId: 225887305
2019-03-29 14:31:13 -07:00
Alex Zinenko df9bd857b1 Type system: replace Type::getBitWidth with getIntOrFloatBitWidth
As MLIR moves towards dialect-specific types, a generic Type::getBitWidth does
not make sense for all of them.  Even with the current type system, the bit
width is not defined (and causes the method in question to abort) for all
TensorFlow types.

This commit restricts the bit width definition to primitive standard types that
have a number of bits appearing verbatim in their type, i.e., integers and
floats.  As a side effect, it delegates the decision on the bit width of the
`index` to the backends.  Existing backends currently hardcode it to 64 bits.

The Type::getBitWidth method is replaced by Type::getIntOrFloatBitWidth that
only applies to integers and floats.  The call sites are updated to use the new
method, where applicable, or rewritten so as not rely on it.  Incidentally,
this fixes a utility method that did not account for memrefs being allowed to
have vectors as element types in the size computation.

As an observation, several places in the code use Type in places where a more
specific type could be used instead.  Some of those are fixed by this commit.

PiperOrigin-RevId: 225844792
2019-03-29 14:30:43 -07:00
Alex Zinenko bc52a639f9 Extract vector_transfer_* Ops into a SuperVectorDialect.
From the beginning, vector_transfer_read and vector_transfer_write opreations
were intended as a mid-level vectorization abstraction.  In particular, they
are lowered to the StandardOps dialect before further processing.  As such, it
does not make sense to keep them at the same level as StandardOps.  Introduce
the new SuperVectorOps dialect and move vector_transfer_* operations there.
This will be used as a testbed for the generic lowering/legalization pass.

PiperOrigin-RevId: 225554492
2019-03-29 14:28:58 -07:00
Alex Zinenko 97d2f3cd3d ConvertToCFG: use affine_apply to implement loop steps
Originally, loop steps were implemented using `addi` and `constant` operations
because `affine_apply` was not handled in the first implementation.  The
support for `affine_apply` has been added, use it to implement the update of
the loop induction variable.  This is more consistent with the lower and upper
bounds of the loop that are also implemented as `affine_apply`, removes the
dependence of the converted function on the StandardOps dialect and makes it
clear from the CFG function that all operations on the loop induction variable
are purely affine.

PiperOrigin-RevId: 225165337
2019-03-29 14:26:22 -07:00
Alex Zinenko 63261aa9a8 Disallow index types as elements of vector, memref and tensor types
An extensive discussion demonstrated that it is difficult to support `index`
types as elements of compound (vector, memref, tensor) types.  In particular,
their size is unknown until the target-specific lowering takes place.  MLIR may
need to store constants of the fixed-shape compound types (e.g.,
vector<4 x index>) internally and must know the size of the element type and
data layout constraints.  The same information is necessary for target-specific
lowering and translation to reliably support compound types with `index`
elements, but MLIR does not have a dedicated target description mechanism yet.

The uses cases for compound types with `index` elements, should they appear,
can be handled via an `index_cast` operation that converts between `index` and
fixed-size integer types at the SSA value level instead of the type level.

PiperOrigin-RevId: 225064373
2019-03-29 14:25:22 -07:00
Nicolas Vasilache 692f6ffdf8 [MLIR] Add LangRef entries for vector_transfer ops
PiperOrigin-RevId: 224535443
2019-03-29 14:22:20 -07:00
Tatiana Shpeisman 8ad72bd6be Make examples semantically meaningful and fix miscellaneous typos. Thanks to @rocky for pointing out the bugs.
PiperOrigin-RevId: 224239160
2019-03-29 14:18:52 -07:00
Alex Zinenko a3fb6d0da3 StandardOps: introduce 'select'.
The semantics of 'select' is conventional: return the second operand if the
first operand is true (1 : i1) and the third operand otherwise.  It is
applicable to vectors and tensors element-wise, similarly to LLVM instruction.
This operation is necessary to implement min/max to lower 'for' loops with
complex bounds to CFG functions and to support ternary operations in ML
functions.  It is preferred to first-class min/max because of its simplicity,
e.g. it is not concered with signedness.

PiperOrigin-RevId: 223160860
2019-03-29 14:11:25 -07:00
Alex Zinenko 67939e8b70 Create Passes.md.
Start the documentation file listing available MLIR passes.  Briefly describe
the `-convert-to-cfg` and the `-lower-affine-apply` passes.  These passes
serve as description templates for other passes.  In particular, they include
the dialect and operation restrictions in the pass input and output.

PiperOrigin-RevId: 223076894
2019-03-29 14:10:27 -07:00
Jacques Pienaar 17b8105761 Fix typo.
Tensor has as element type a tensor-memref-element-type rather than a vector-element-type.

PiperOrigin-RevId: 223062135
2019-03-29 14:10:12 -07:00
River Riddle 1c95796372 Update 'return' statement syntax in LangRef to reflect the actual parsing syntax.
PiperOrigin-RevId: 222107722
2019-03-29 14:01:48 -07:00
Chris Lattner a603b2f5b2 Import the "MLIR: The case for a simplified polyhedral form" proposal doc from
google docs into the codebase as a rationale doc, since this is an important
aspect of our design.

PiperOrigin-RevId: 221957444
2019-03-29 14:01:19 -07:00
Jacques Pienaar 8c903a3c9d Update LangRef to reflect int/flaot attribute specification changes.
PiperOrigin-RevId: 221802835
2019-03-29 14:00:23 -07:00
Chris Lattner a30f7ec74f Fix some minor typos pointed out by rxwei
PiperOrigin-RevId: 221474217
2019-03-29 13:57:31 -07:00
Jacques Pienaar fb4b74ccb3 Mark mlir code snippets as being written in mlir
Forgot to add these in previous change :/

PiperOrigin-RevId: 221444322
2019-03-29 13:57:16 -07:00
Jacques Pienaar b1f7e03add Mark mlir code snippets as being written in mlir
Basic MLIR syntax highlighting is supported so use it.

PiperOrigin-RevId: 221443618
2019-03-29 13:57:02 -07:00
Alex Zinenko cab24dc211 Homogenize branch instruction arguments.
Branch instruction arguments were defined and used inconsistently across
different instructions, in both the spec and the implementation.  In
particular, conditional and unconditional branch instructions were using
different syntax in the implementation.  This led to the IR we produce not
being accepted by the parser. Update the printer to use common syntax: `(`
list-of-SSA-uses `:` list-of-types `)`.  The motivation for choosing this
syntax as opposed to the one in the spec, `(` list-of-SSA-uses `)` `:`
list-of-types is double-fold.  First, it is tricky to differentiate the label
of the false branch from the type while parsing conditional branches (which is
what apparently motivated the implementation to diverge from the spec in the
first place).  Second, the ongoing convergence between terminator instructions
and other operations prompts for consistency between their operand list syntax.
After this change, the only remaining difference between the two is the use of
parentheses.  Update the comment of the parser that did not correspond to the
code.  Remove the unused isParenthesized argument from parseSSAUseAndTypeList.

Update the spec accordingly.  Note that the examples in the spec were _not_
using the EBNF defined a couple of lines above them, but were using the current
syntax.  Add a supplementary example of a branch to a basic block with multiple
arguments.

PiperOrigin-RevId: 221162655
2019-03-29 13:55:36 -07:00
MLIR Team b2f77e1b8f Change the index upper bound for the outer-loop as the comment says the array has 8 rows.
PiperOrigin-RevId: 221082461
2019-03-29 13:54:53 -07:00
Chris Lattner 86a5323f04 - Simplify PatternMatch to *require* static benefits at pattern construction
time.  The "Fast and Flexible Instruction Selection With Constraints" paper
  from CC2018 makes a credible argument that dynamic costs aren't actually
  necessary/important, and we are not using them.

- Check in my "MLIR Generic DAG Rewriter Infrastructure" design doc into the
  source tree.

PiperOrigin-RevId: 221017546
2019-03-29 13:54:38 -07:00
Chris Lattner d469a5d675 Add the "MLIR: Incremental Application to TensorFlow Graph Algorithms" document
I wrote last weekend.

PiperOrigin-RevId: 221017318
2019-03-29 13:54:24 -07:00
Alex Zinenko 846e48d16f Allow vector types to have index elements.
It is unclear why vector types were not allowed to have "index" as element
type.  Index values are integers, although of unknown bit width, and should
behave as such.  Vectors of integers are allowed and so are tensors of indices
(for indirection purposes), it is more consistent to also have vectors of
indices.

PiperOrigin-RevId: 220630123
2019-03-29 13:51:33 -07:00
Alex Zinenko ac2a655e87 Enable arithmetics for index types.
Arithmetic and comparison instructions are necessary to implement, e.g.,
control flow when lowering MLFunctions to CFGFunctions.  (While it is possible
to replace some of the arithmetics by affine_apply instructions for loop
bounds, it is still necessary for loop bounds checking, steps, if-conditions,
non-trivial memref subscripts, etc.)  Furthermore, working with indirect
accesses in, e.g., lookup tables for large embeddings, may require operating on
tensors of indexes.  For example, the equivalents to C code "LUT[Index[i]]" or
"ResultIndex[i] = i + j" where i, j are loop induction variables require the
arithmetics on indices as well as the possibility to operate on tensors
thereof.  Allow arithmetic and comparison operations to apply to index types by
declaring them integer-like.  Allow tensors whose element type is index for
indirection purposes.

The absence of vectors with "index" element type is explicitly tested, but the
only justification for this restriction in the CL introducing the test is
"because we don't need them".  Do NOT enable vectors of index types, although
it makes vector and tensor types inconsistent with respect to allowed element
types.

PiperOrigin-RevId: 220614055
2019-03-29 13:51:19 -07:00
Alex Zinenko 3a38a5d0d6 Introduce integer comparison operation.
This binary operation is applicable to integers, vectors and tensors thereof
similarly to binary arithmetic operations.  The operand types must match
exactly, and the shape of the result type is the same as that of the operands.
The element type of the result is always i1.  The kind of the comparison is
defined by the "predicate" integer attribute.  This attribute requests one of:
- equals to;
- not equals to;
- signed less than;
- signed less than or equals;
- signed greater than;
- signed greater than or equals;
- unsigned less than;
- unsigned less than or equals;
- unsigned greater than;
- unsigned greater than or equals.
Since integer values themselves do not have a sign, the comparison operator
specifies whether to use signed or unsigned comparison logic, i.e. whether to
interpret values where the foremost bit is set as negatives expressed as two's
complements or as positive values.  For non-scalar operands, pairwise
per-element comparison is performed.  Comparison operators on scalars are
necessary to implement basic control flow with conditional branches.

PiperOrigin-RevId: 220613566
2019-03-29 13:50:49 -07:00
MLIR Team 710b20aeb1 Fix formatting of mlir snippet.
PiperOrigin-RevId: 219535523
2019-03-29 13:46:36 -07:00
Chris Lattner a10cd107de Introduce a common base class (IROperandOwner) between Instruction and
Statement, which paves the way to make SSAValue's have a useful owner
available, which will allow subsequent patches to improve their use/def
chains.

While I'm poking at this, shrink sizeof(Instruction) and sizeof(Statement) by a
word by packing the kind and location together into a single PointerIntPair.

NFC.

PiperOrigin-RevId: 218959651
2019-03-29 13:42:32 -07:00
Chris Lattner 967d934180 Fix two issues:
1) We incorrectly reassociated non-reassociative operations like subi, causing
    miscompilations.
 2) When constant folding, we didn't add users of the new constant back to the
    worklist for reprocessing, causing us to miss some cases (pointed out by
    Uday).

The code for tensorflow/mlir#2 is gross, but I'll add the new APIs in a followup patch.

PiperOrigin-RevId: 218803984
2019-03-29 13:40:35 -07:00
Chris Lattner 144795e35c Add a doc explaining our approach to canonicalization, which is more of a
framework than a useful doc at this point.

PiperOrigin-RevId: 218737032
2019-03-29 13:38:38 -07:00
Alex Zinenko e8d254b909 Rename shape_cast to tensor_cast.
"shape_cast" only applies to tensors, and there are other operations that
actually affect shape, for example "reshape".  Rename "shape_cast" to
"tensor_cast" in both the code and the documentation.

PiperOrigin-RevId: 218528122
2019-03-29 13:37:41 -07:00
Alex Zinenko c1b0918617 Add MLIR Rationale converted to g3doc.
This CL only converts the document to the g3doc format and does some minor
typesetting, e.g. removing unicode ellipsis and mdash symbols, replace single
quotes with backticks to trigger tt-type dispay, etc.  The original document
is located at
https://docs.google.com/document/d/1KoVYgp-m-dgAyKwqRne2c72j0FoxpsdNgfa9DTfWGgw/view
Links to the sections of the same document are updated to point to the anchors
in the converted document whereas links to external documents are kept as is.
Cross-links between LangRef.md and Rationale.md are updated to point to the
relevant anchors in the g3doc files.

PiperOrigin-RevId: 218527560
2019-03-29 13:37:27 -07:00
Alex Zinenko 1321f6affd Add MLIR specification.
PiperOrigin-RevId: 218527452
2019-03-29 13:37:13 -07:00