| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, regions can only be constructed by passing in a `Function` or an
`Instruction` pointer referencing the parent object, unlike `Function`s or
`Instruction`s themselves that can be created without a parent. It leads to a
rather complex flow in operation construction where one has to create the
operation first before being able to work with its regions. It may be
necessary to work with the regions before the operation is created. In
particular, in `build` and `parse` functions that are executed _before_ the
operation is created in cases where boilerplate region manipulation is required
(for example, inserting the hypothetical default terminator in affine regions).
Allow creating standalone regions. Such regions are meant to own a list of
blocks and transfer them to other regions on demand.
Each instruction stores a fixed number of regions as trailing objects and has
ownership of them. This decreases the size of the Instruction object for the
common case of instructions without regions. Keep this behavior intact. To
allow some flexibility in construction, make OperationState store an owning
vector of regions. When the Builder creates an Instruction from
OperationState, the bodies of the regions are transferred into the
instruction-owned regions to minimize copying. Thus, it becomes possible to
fill standalone regions with blocks and move them to an operation when it is
constructed, or move blocks from a region to an operation region, e.g., for
inlining.
PiperOrigin-RevId: 240368183
|
|
|
|
|
|
| |
from Function.
PiperOrigin-RevId: 239638635
|
|
|
|
|
|
| |
NFC. This is step 1/n to specifying regions as parts of any operation.
PiperOrigin-RevId: 238472370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug: previously, during conversion function argument
attributes were neither beings passed through nor converted. This fix
extends DialectConversion to allow for simultaneous conversion of the
function type and the argument attributes.
This was important when lowering MLIR to LLVM where attribute
information (e.g. noalias) needs to be preserved in MLIR(LLVMDialect).
Longer run it seems reasonable that we want to convert both the
function attribute and its type and the argument attributes, but that
requires a small refactoring in Function.h to aggregate these three
fields in an inner struct, which will require some discussion.
PiperOrigin-RevId: 236709409
|
|
|
|
|
|
|
|
|
|
| |
is printed after the argument type:
func @arg_attrs(i32 {arg_attr: 10})
func @arg_attrs(%arg0: i32 {arg_attr: 10})
PiperOrigin-RevId: 236136830
|
|
|
|
|
|
| |
between Function and Instruction.
PiperOrigin-RevId: 235830304
|
|
|
|
|
|
| |
Function/Block/Instruction.
PiperOrigin-RevId: 232388113
|
|
|
|
|
|
| |
the Instruction variants.
PiperOrigin-RevId: 232322030
|
|
|
|
|
|
| |
remapping successor block operands of terminator operations. We define a new BlockAndValueMapping class to simplify mapping between cloned values.
PiperOrigin-RevId: 230768759
|
|
|
|
|
|
| |
and call it when clearing the block. This fixes a bug where ForInst/IfInst instructions may still have references to values while being destroyed.
PiperOrigin-RevId: 229207798
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The entire compiler now looks at structural properties of the function (e.g.
does it have one block, does it contain an if/for stmt, etc) so the only thing
holding up this difference is round tripping through the parser/printer syntax.
Removing this shrinks the compile by ~140LOC.
This is step 31/n towards merging instructions and statements. The last step
is updating the docs, which I will do as a separate patch in order to split it
from this mostly mechanical patch.
PiperOrigin-RevId: 227540453
|
|
|
|
|
|
|
|
|
|
|
| |
Function::walk functionality into f->walkInsts/Ops which allows visiting all
instructions, not just ops. Eliminate Function::getBody() and
Function::getReturn() helpers which crash in CFG functions, and were only kept
around as a bridge.
This is step 25/n towards merging instructions and statements.
PiperOrigin-RevId: 227243966
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Function.
This is step 18/n towards merging instructions and statements, NFC.
PiperOrigin-RevId: 227139399
|
|
|
|
|
|
|
|
| |
OperationInst. This is a big mechanical patch.
This is step 16/n towards merging instructions and statements, NFC.
PiperOrigin-RevId: 227093712
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExtFunction classes, using the Statement/StmtBlock hierarchy and Function instead.
This *only* changes the internal data structures, it does not affect the user visible syntax or structure of MLIR code. Function gets new "isCFG()" sorts of predicates as a transitional measure.
This patch is gross in a number of ways, largely in an effort to reduce the amount of mechanical churn in one go. It introduces a bunch of using decls to keep the old names alive for now, and a bunch of stuff needs to be renamed.
This is step 10/n towards merging instructions and statements, NFC.
PiperOrigin-RevId: 227044402
|
|
|
|
|
|
|
|
|
|
|
| |
use the
BlockArgument arguments of the entry block instead. This makes MLFunctions and
CFGFunctions work more similarly.
This is step 7/n towards merging instructions and statements, NFC.
PiperOrigin-RevId: 226966975
|
|
|
|
|
|
|
|
|
| |
MLFunction, IfStmt, ForStmt even though they currently only contain exactly one
block in that list.
This is step 6/n towards merging instructions and statements, NFC.
PiperOrigin-RevId: 226960278
|
|
|
|
|
|
|
|
|
|
| |
from it. This is necessary progress to squaring away the parent relationship
that a StmtBlock has with its enclosing if/for/fn, and makes room for functions
to have more than one block in the future. This also removes IfClause and ForStmtBody.
This is step 5/n towards merging instructions and statements, NFC.
PiperOrigin-RevId: 226936541
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies call-sites returning true after emitting an error. After the
conversion, dropped braces around single statement blocks as that seems more
common.
Also, switched to emitError method instead of emitting Error kind using the
emitDiagnostic method.
TESTED with existing unit tests
PiperOrigin-RevId: 224527868
|
|
|
|
| |
PiperOrigin-RevId: 221700132
|
|
|
|
|
|
| |
Value type abstraction for locations differ from others in that a Location can NOT be null. NOTE: dyn_cast returns an Optional<T>.
PiperOrigin-RevId: 220682078
|
|
|
|
|
|
| |
This is done by changing Type to be a POD interface around an underlying pointer storage and adding in-class support for isa/dyn_cast/cast.
PiperOrigin-RevId: 219372163
|
|
|
|
|
|
| |
operations. This is a simplified form for the existing walker API.
PiperOrigin-RevId: 216754991
|
|
|
|
| |
PiperOrigin-RevId: 213540509
|
|
|
|
|
|
|
|
|
|
|
| |
- Compress the identifier/kind of a Function into a single word.
- Eliminate otherFailure from verifier now that we always have a location
- Eliminate the error string from the verifier now that we always have
locations.
- Simplify the parser's handling of fn forward references, using the location
tracked by the function.
PiperOrigin-RevId: 211985101
|
|
|
|
|
|
|
|
|
|
| |
resolver support.
Still TODO are verifier support (to make sure you don't use an attribute for a
function in another module) and the TODO in ModuleParser::finalizeModule that I
will handle in the next patch.
PiperOrigin-RevId: 209361648
|
|
|
|
|
|
|
| |
names across the module and auto-renaming conflicts. Have the parser reject
malformed modules that have redefinitions.
PiperOrigin-RevId: 209227560
|
|
|
|
| |
PiperOrigin-RevId: 208514441
|
|
|
|
|
|
|
|
| |
Function using TrailingObjects template. Implement argument iterators, parsing and printing.
Unrelated minor change - remove OperationStmt::dropReferences(). Since MLFunction does not have cyclic operand references (it's an AST) destruction can be safely done w/o a special pass to drop references.
PiperOrigin-RevId: 207583024
|
|
|
|
|
|
|
|
|
|
| |
This CL adds:
* One graphdef extracted from the TF test suite. More will come.
* Scaffolding for the "graphdef2mlir" tool.
* Importing of simple graphs. Type inference is not yet working, and attributes do not work either.
* A fix for CFGFunction::~CFGFunction to not die if the function was destroyed without a terminator (for example if we exit early due to an error).
PiperOrigin-RevId: 206965992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Update InnermostLoopGatherer to use a post order traversal (linear
time/single traversal).
- Drop getNumNestedLoops().
- Update isInnermost() to use the StmtWalker.
When using return values in conjunction with walkers, the StmtWalker CRTP
pattern doesn't appear to be of any use. It just requires overriding nearly all
of the methods, which is what InnermostLoopGatherer currently does. Please see
FIXME/ENLIGHTENME comments. TODO: figure this out from this CL discussion.
Note
- Comments on visitor/walker base class are out of date; will update when this
CL is finalized.
PiperOrigin-RevId: 206340901
|
|
|
|
|
|
| |
values. ML functions now have full support for expressing operations. Induction variables, function arguments and return values are still todo.
PiperOrigin-RevId: 206253643
|
|
|
|
|
|
|
| |
Give BasicBlock a use/def list, making references to them in TerminatorInst's
into a type that maintains the list.
PiperOrigin-RevId: 206166388
|
|
|
|
|
|
|
|
|
| |
pointer, and ensure that functions are deleted when the module is destroyed.
This exposed the fact that MLFunction had no dtor, and that the dtor in
CFGFunction was broken with cyclic references. Fix both of these problems.
PiperOrigin-RevId: 206051666
|
|
|
|
| |
PiperOrigin-RevId: 204614520
|
|
|
|
|
|
| |
Use LLVM double-link with parent list to store statements within a block.
PiperOrigin-RevId: 204515541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
properties:
- They allow type checked dynamic casting from their base Operation.
- They allow nice accessors for C++ clients, e.g. a "getIndex()" method on
'dim' that returns an unsigned.
- They work with both OperationInst/OperationStmt (once OperationStmt is
implemented).
- They get custom printing logic. They will eventually get custom parsing,
verifier, and builder logic as well.
- Out of tree clients can register their own operation set without having to
change MLIR core, e.g. for TensorFlow or custom target instructions.
This registers addf and dim as examples.
PiperOrigin-RevId: 203382993
|
|
|
|
|
|
|
| |
Representing function arguments is still TODO.
Supporting instructions other than return is also TODO.
PiperOrigin-RevId: 202570934
|
|
|
|
|
|
|
|
|
|
| |
instruction.
This is pretty much minimal scaffolding for this step. Basic block arguments,
instructions, other terminators, a proper IR representation for
blocks/instructions, etc are all coming.
PiperOrigin-RevId: 201826439
|
|
|
|
|
|
|
|
|
| |
vector types.
tensors and memref types are still TODO, and would be a good starter project
for someone.
PiperOrigin-RevId: 201782748
|
|
|
|
|
|
|
| |
filename, and printing of trivial stuff. There is no parser yet, so the
input file is ignored.
PiperOrigin-RevId: 201596916
|
|
PiperOrigin-RevId: 201540159
|