Commit Graph

34 Commits

Author SHA1 Message Date
River Riddle e7d594bb1c Replace the implementation of Function and Module with FuncOp and ModuleOp.
This is an important step in allowing for the top-level of the IR to be extensible. FuncOp and ModuleOp contain all of the necessary functionality, while using the existing operation infrastructure. As an interim step, many of the usages of Function and Module, including the name, will remain the same. In the future, many of these will be relaxed to allow for many different types of top-level operations to co-exist.

PiperOrigin-RevId: 256427100
2019-07-03 14:37:18 -07:00
Alex Zinenko 3d62ef8018 Update region documentation
Restructure the Regions section in LangRef to avoid having a wall of text and
    reflect a recent evolution of the design.  Unspecify region types, that are put
    on hold until use cases arise.

    Update the Rationale doc with a list of design decisions related to regions.
    Separately list the design alternatives that were considered and discarded due
    to the lack of existing use cases.

--

PiperOrigin-RevId: 247943144
2019-05-20 13:38:22 -07:00
Chris Lattner 4d243f138a Update the Rationale's description about signed/unsigned and int/fp types to be more specific about the fact that this only refers to std operations. Move these sections closer together.
--

PiperOrigin-RevId: 243204948
2019-04-18 11:47:18 -07:00
River Riddle 465ef55088 Tidy up the links in the documents and fix any broken ones.
--

PiperOrigin-RevId: 242127863
2019-04-07 18:19:46 -07:00
Mehdi Amini 3a2955fa1f Rename UnknownType to OpaqueType (NFC)
This came up in a review of the tutorial, it was suggested that "opaque" is more
    descriptive than "unknown" here.

--

PiperOrigin-RevId: 241832927
2019-04-03 19:21:47 -07:00
Chris Lattner 7bf06e6038 Remove links to internal google docs, updating them to point to GitHub.
--

PiperOrigin-RevId: 241800478
2019-04-03 19:20:50 -07:00
River Riddle 90d2e16e63 Replace usages of instruction with operation in the g3 documents.
PiperOrigin-RevId: 241037784
2019-03-29 17:56:57 -07:00
River Riddle 3ddd0411d0 Slight rewording of TupleType rationale.
PiperOrigin-RevId: 240991400
2019-03-29 17:55:21 -07:00
River Riddle 832567b379 NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and set the namespace of the AffineOps dialect to 'affine'.
PiperOrigin-RevId: 240165792
2019-03-29 17:39:03 -07:00
River Riddle 9c6e92360c NFC: Rename the 'if' operation in the AffineOps dialect to 'affine.if'.
PiperOrigin-RevId: 240071154
2019-03-29 17:36:53 -07:00
River Riddle 30e68230bd Add support for a standard TupleType. Though this is a standard type, it merely provides a common mechanism for representing tuples in MLIR. It is up to dialect authors to provides operations for manipulating them, e.g. extract_tuple_element.
TupleType has the following form:
   tuple-type ::= `tuple` `<` (type (`,` type)*)? `>`

Example:

// Empty tuple.
tuple<>

// Single element.
tuple<i32>

// Multi element.
tuple<i32, tuple<f32>, i16>

PiperOrigin-RevId: 239226021
2019-03-29 17:25:09 -07:00
Uday Bondhugula c419accea3 Automated rollback of changelist 232728977.
PiperOrigin-RevId: 232944889
2019-03-29 16:21:38 -07:00
Uday Bondhugula 4ba8c9147d Automated rollback of changelist 232717775.
PiperOrigin-RevId: 232807986
2019-03-29 16:19:33 -07:00
River Riddle fd2d7c857b Rename the 'if' operation in the AffineOps dialect to 'affine.if' and namespace
the AffineOps dialect with 'affine'.

PiperOrigin-RevId: 232728977
2019-03-29 16:18:59 -07:00
River Riddle 90d10b4e00 NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for'. The is the second step to adding a namespace to the AffineOps dialect.
PiperOrigin-RevId: 232717775
2019-03-29 16:17:59 -07:00
River Riddle 3227dee15d NFC: Rename affine_apply to affine.apply. This is the first step to adding a namespace to the affine dialect.
PiperOrigin-RevId: 232707862
2019-03-29 16:17:29 -07:00
River Riddle 6f7470a56a Define the initial g3doc for the Affine dialect.
PiperOrigin-RevId: 232581506
2019-03-29 16:15:26 -07:00
Chris Lattner b42bea215a Change AffineApplyOp to produce a single result, simplifying the code that
works with it, and updating the g3docs.

PiperOrigin-RevId: 231120927
2019-03-29 15:40:38 -07:00
Lei Zhang 5654450853 Unify terms regarding assembly form to use generic vs. custom
This CL just changes various docs and comments to use the term "generic" and
"custom" when mentioning assembly forms. To be consist, several methods are
also renamed:

* FunctionParser::parseVerboseOperation() -> parseGenericOperation()
* ModuleState::hasShorthandForm() -> hasCustomForm()
* OpAsmPrinter::printDefaultOp() -> printGenericOp()

PiperOrigin-RevId: 230568819
2019-03-29 15:32:35 -07:00
River Riddle 8eccc429b7 Add parser support for named type aliases.
Alias identifiers can be used in the place of the types that they alias, and are defined as:

    type-alias-def ::= '!' alias-name '=' 'type' type
    type-alias ::= '!' alias-name

Example:

    !avx.m128 = type vector<4 x f32>
    ...

    "foo"(%x) : vector<4 x f32> -> ()

    // becomes:

    "foo"(%x) : !avx.m128 -> ()

PiperOrigin-RevId: 228271372
2019-03-29 15:04:05 -07:00
River Riddle bee0b83cef Update the langref to include the rationale and specification of the dialect extended type system.
PiperOrigin-RevId: 228184876
2019-03-29 15:01:26 -07:00
Chris Lattner 8ebd64b32f Update the g3docs to reflect the merging of CFG and ML functions.
PiperOrigin-RevId: 227562943
2019-03-29 14:51:52 -07:00
Chris Lattner 37579ae8c4 Introduce ^ as a basic block sigil, eliminating an ambiguity on the MLIR
syntax.

PiperOrigin-RevId: 227234174
2019-03-29 14:45:59 -07:00
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
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 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
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
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
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
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
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