summaryrefslogtreecommitdiffstats
path: root/mlir/lib/EDSC
Commit message (Collapse)AuthorAgeFilesLines
...
* Make FunctionPass::getFunction() return a reference to the function, instead ofChris Lattner2019-03-291-1/+1
| | | | | | | a pointer. This makes it consistent with all the other methods in FunctionPass, as well as with ModulePass::getModule(). NFC. PiperOrigin-RevId: 240257910
* Replace usages of "Op::operator->" with ".".River Riddle2019-03-291-2/+2
| | | | | | This is step 2/N of removing the temporary operator-> method as part of the de-const transition. PiperOrigin-RevId: 240200792
* Replace usages of "operator->" with "." for the AffineOps.River Riddle2019-03-293-9/+9
| | | | | Note: The "operator->" method is a temporary helper for the de-const transition and is gradually being phased out. PiperOrigin-RevId: 240179439
* NFC: Rename the 'for' operation in the AffineOps dialect to 'affine.for' and ↵River Riddle2019-03-292-4/+5
| | | | | | set the namespace of the AffineOps dialect to 'affine'. PiperOrigin-RevId: 240165792
* Remove OpPointer, cleaning up a ton of code. This also moves Ops to usingChris Lattner2019-03-292-18/+15
| | | | | | | | | inherited constructors, which is cleaner and means you can now use DimOp() to get a null op, instead of having to use Instruction::getNull<DimOp>(). This removes another 200 lines of code. PiperOrigin-RevId: 240068113
* Remove const from Value, Instruction, Argument, and the various methods on theChris Lattner2019-03-291-2/+2
| | | | | | *Op classes. This is a net reduction by almost 400LOC. PiperOrigin-RevId: 239972443
* Make edsc::IndexedValue templated - NFCNicolas Vasilache2019-03-291-35/+0
| | | | | | | This allows the indexing sugar to just work naturally with other type of load and store ops than the affine ones we currently have. This is needed for the EuroLLVM tutorial. PiperOrigin-RevId: 239602257
* Cleanups Vectorize and SliceAnalysis - NFCNicolas Vasilache2019-03-291-0/+2
| | | | | | This CL cleans up and refactors super-vectorization and slice analysis. PiperOrigin-RevId: 238986866
* Port Tablegen'd reference implementation of Add to declarative builders.Nicolas Vasilache2019-03-291-2/+2
| | | | PiperOrigin-RevId: 238977252
* Remove LOAD/STORE/RETURN boilerplate in declarative builders.Nicolas Vasilache2019-03-292-32/+8
| | | | | | | | | | | | | This CL introduces a ValueArrayHandle helper to manage the implicit conversion of ArrayRef<ValueHandle> -> ArrayRef<Value*> by converting first to ValueArrayHandle. Without this, boilerplate operations that take ArrayRef<Value*> cannot be removed easily. This all seems to boil down to decoupling Value from Type. Alternative solutions exist (e.g. MLIR using Value by value everywhere) but they would be very intrusive. This seems to be the lowest impedance change. Intrinsics are also lowercased by popular demand. PiperOrigin-RevId: 238974125
* Port LowerVectorTransfers from EDSC + AST to declarative buildersNicolas Vasilache2019-03-293-25/+49
| | | | | | | | | | | | | | | This CL removes the dependency of LowerVectorTransfers on the AST version of EDSCs which will be retired. This exhibited a pretty fundamental staging difference in AST-based vs declarative based emission. Since the delayed creation with an AST was staged, the loop order came into existence after the clipping expressions were computed. This now changes as the loops first need to be created declaratively in fixed order and then the clipping expressions are created. Also, due to lack of staging, coalescing cannot be done on the fly anymore and needs to be done either as a pre-pass (current implementation) or as a local transformation on the generated IR (future work). Tests are updated accordingly. PiperOrigin-RevId: 238971631
* Python bindings: expose boolean and comparison operatorsAlex Zinenko2019-03-291-0/+15
| | | | | | | | | | | | | | | | | In particular, expose comparison operators as Python operator overloads on ValueHandles. The comparison currently emits signed integer comparisons only, which is compatible with the behavior of emitter-based EDSC interface. This is sub-optimal and must be reconsidered in the future. Note that comparison operators are not overloaded in the C++ declarative builder API precisely because this avoids the premature decision on the signedness of comparisons. Implement the declarative construction of boolean expressions using ValueHandles by overloading the boolean operators in the `op` namespace to differentiate between `operator!` for nullity check and for boolean negation. The operands must be of i1 type. Also expose boolean operations as Python operator overloads on ValueHandles. PiperOrigin-RevId: 238421615
* [EDSC] Cleanup declarative builder insertion point with blocksNicolas Vasilache2019-03-292-16/+9
| | | | | | | | | | | | | Declarative builders want to provide the same nesting interface for blocks and loops. MLIR on the other hand has different behaviors: 1. when an AffineForOp is created the insertion point does not enter the loop body; 2. when a Block is created, the insertion point does enter the block body. Guard against the second behavior in EDSC to make the interface unsurprising. This also surfaces two places in the eager branch API where I was guarding against this behavior indirectly by creating a new ScopedContext. Instead, uniformize everything to properly reset the insertion point in the unique place that builds the mlir::Block*. PiperOrigin-RevId: 237619513
* Follow up on custom instruction support.Nicolas Vasilache2019-03-291-3/+3
| | | | | | | | | This CL addresses a few post-submit comments: 1. better comments, 2. check number of results before dyn_cast (which is a less common case) 3. test usage for multi-result InstructionHandle PiperOrigin-RevId: 237549333
* Add support for custom ops in declarative builders.Nicolas Vasilache2019-03-293-23/+58
| | | | | | | | This CL adds support for named custom instructions in declarative builders. To allow this, it introduces a templated `CustomInstruction` class. This CL also splits ValueHandle which can capture only the **value** in single-valued instructions from InstructionHandle which can capture any instruction but provide no typing and sugaring to extract the potential Value*. PiperOrigin-RevId: 237543222
* Fix opt build.MLIR Team2019-03-291-0/+1
| | | | PiperOrigin-RevId: 237141751
* Fix an incorrect comment in builder-api-test.Nicolas Vasilache2019-03-291-2/+0
| | | | | | Also address post commit cleanups that were missed. PiperOrigin-RevId: 237122077
* Add helper classes to declarative builders to help write end-to-end custom ops.Nicolas Vasilache2019-03-293-0/+149
| | | | | | | | This CL adds the same helper classes that exist in the AST form of EDSCs to support a basic indexing notation and emit the proper load and store operations and capture MemRefViews as function arguments. This CL also adds a wrapper class LoopNestBuilder to allow generic rank-agnostic loops over indices. PiperOrigin-RevId: 237113755
* Hotfix for unused variable in opt modeNicolas Vasilache2019-03-291-0/+1
| | | | PiperOrigin-RevId: 237073601
* [EDSC] Hotfix: Avoid implicit OpPointer -> OpType* conversionNicolas Vasilache2019-03-291-3/+3
| | | | | | | An implicit OpPointer -> OpType* conversion results in AddressSanitizer triggering a stack-use-after-scope error (which may be a false positive). Avoid using such patterns to make life good again. PiperOrigin-RevId: 237053863
* Add an eager API version for BR and COND_BRNicolas Vasilache2019-03-291-0/+54
| | | | | | | | | | When building unstructured control-flow there is a need to construct mlir::Block* before being able to fill them. This invites goto-style programming. This CL introduces an alternative eager API for BR and COND_BR in which blocks are created eagerly and captured on the fly. This allows reducing the number of calls to `BlockBuilder` from 4 to 2 in the `builder_blocks_eager` test and from 3 to 2 in the `builder_cond_branch_eager` test. PiperOrigin-RevId: 237046114
* Add support for Branches in edsc::BuilderNicolas Vasilache2019-03-292-2/+63
| | | | | | | | | This CL adds support for BranchHandle and BranchBuilder that require a slightly different abstraction since an mlir::Block is not an mlir::Value. This CL also adds support for the BR and COND_BR instructions and the relevant tests. PiperOrigin-RevId: 237034312
* Start a new implementation for edsc::BuilderNicolas Vasilache2019-03-292-0/+294
| | | | | | | | | | | | | | | | | This CL reworks the design of EDSCs from first principles. It introduces a ValueHandle which can hold either: 1. an eagerly typed, delayed Value* 2. a precomputed Value* A ValueHandle can be manipulated with intrinsic operations a nested within a NestedBuilder. These NestedBuilder are a more idiomatic nested builder abstraction that should feel intuitive to program in C++. Notably, this abstraction does not require an AST to stage the construction of MLIR snippets from C++. Instead, the abstraction makes use of orderings between definition and declaration of ValueHandles and provides a NestedBuilder and a LoopBuilder helper classes to handle those orderings. All instruction creations are meant to use the templated ValueHandle::create<> which directly calls mlir::Builder.create<>. For now the EDSC AST and the builders live side-by-side until the C API is ported. PiperOrigin-RevId: 237030945
* Change Pass:getFunction() to return pointer instead of ref - NFCUday Bondhugula2019-03-291-1/+1
| | | | | | | | | - change this for consistency - everything else similar takes/returns a Function pointer - the FuncBuilder ctor, Block/Value/Instruction::getFunction(), etc. - saves a whole bunch of &s everywhere PiperOrigin-RevId: 236928761
* Set the namespace of the StandardOps dialect to "std", but add a special ↵River Riddle2019-03-291-1/+1
| | | | | | case to the parser to allow parsing standard operations without the "std" prefix. This will now allow for the standard dialect to be looked up dynamically by name. PiperOrigin-RevId: 236493865
* NFC. Move all of the remaining operations left in BuiltinOps to StandardOps. ↵River Riddle2019-03-293-3/+0
| | | | | | The only thing left in BuiltinOps are the core MLIR types. The standard types can't be moved because they are referenced within the IR directory, e.g. in things like Builder. PiperOrigin-RevId: 236403665
* Use consistent names for dialect op source filesLei Zhang2019-03-293-3/+3
| | | | | | | | | | | | | | | This CL changes dialect op source files (.h, .cpp, .td) to follow the following convention: <full-dialect-name>/<dialect-namespace>Ops.{h|cpp|td} Builtin and standard dialects are specially treated, though. Both of them do not have dialect namespace; the former is still named as BuiltinOps.* and the latter is named as Ops.*. Purely mechanical. NFC. PiperOrigin-RevId: 236371358
* EDSC bindings: expose generic Op construction interfaceAlex Zinenko2019-03-291-0/+49
| | | | | | | | | | | | | | | | EDSC Expressions can now be used to build arbitrary MLIR operations identified by their canonical name, i.e. the name obtained from `OpClass::getOperationName()` for registered operations. Expose this functionality to the C API and Python bindings. This exposes builder-level interface to Python and avoids the need for experimental Python code to implement EDSC free function calls for constructing each op type. This modification required exposing mlir::Attribute to the C API and Python bindings, which only supports integer attributes for now. This is step 4/n to making EDSCs more generalizable. PiperOrigin-RevId: 236306776
* Remove PassResult and have the runOnFunction/runOnModule functions return ↵River Riddle2019-03-291-3/+2
| | | | | | void instead. To signal a pass failure, passes should now invoke the 'signalPassFailure' method. This provides the equivalent functionality when needed, but isn't an intrusive part of the API like PassResult. PiperOrigin-RevId: 236202029
* Port all of the existing passes over to the new pass manager infrastructure. ↵River Riddle2019-03-291-7/+4
| | | | | | This is largely NFC. PiperOrigin-RevId: 235952357
* EDSC: move FileCheck tests into the source fileAlex Zinenko2019-03-291-261/+0
| | | | | | | | | | | | | | | | | | EDSC provide APIs for constructing and modifying the IR. These APIs are currently tested by a "test" module pass that reads the dummy IR (empty functions), recognizes certain function names and injects the IR into those functions based on their name. This situation is unsatisfactory because the expected outcome of the test lives in a different file than the input to the test, i.e. the API calls. Create a new binary for tests that constructs the IR from scratch using EDSC APIs and prints it. Put FileCheck comments next to the printing. This removes the need to have a file with dummy inputs and assert on its contents in the test driver. The test source includes a simplistic test harness that runs all functions marked as TEST_FUNC but intentionally does not include any value-testing functionality. PiperOrigin-RevId: 235886629
* Add a stripmineSink and imperfectly nested tiling primitives.Nicolas Vasilache2019-03-292-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL adds a primitive to perform stripmining of a loop by a given factor and sinking it under multiple target loops. In turn this is used to implement imperfectly nested loop tiling (with interchange) by repeatedly calling the stripmineSink primitive. The API returns the point loops and allows repeated invocations of tiling to achieve declarative, multi-level, imperfectly-nested tiling. Note that this CL is only concerned with the mechanical aspects and does not worry about analysis and legality. The API is demonstrated in an example which creates an EDSC block, emits the corresponding MLIR and applies imperfectly-nested tiling: ```cpp auto block = edsc::block({ For(ArrayRef<edsc::Expr>{i, j}, {zero, zero}, {M, N}, {one, one}, { For(k1, zero, O, one, { C({i, j, k1}) = A({i, j, k1}) + B({i, j, k1}) }), For(k2, zero, O, one, { C({i, j, k2}) = A({i, j, k2}) + B({i, j, k2}) }), }), }); // clang-format on emitter.emitStmts(block.getBody()); auto l_i = emitter.getAffineForOp(i), l_j = emitter.getAffineForOp(j), l_k1 = emitter.getAffineForOp(k1), l_k2 = emitter.getAffineForOp(k2); auto indicesL1 = mlir::tile({l_i, l_j}, {512, 1024}, {l_k1, l_k2}); auto l_ii1 = indicesL1[0][0], l_jj1 = indicesL1[1][0]; mlir::tile({l_jj1, l_ii1}, {32, 16}, l_jj1); ``` The edsc::Expr for the induction variables (i, j, k_1, k_2) provide the programmatic hooks from which tiling can be applied declaratively. PiperOrigin-RevId: 235548228
* EDSC: support conditional branch instructionsAlex Zinenko2019-03-293-10/+86
| | | | | | | | | | | | | Leverage the recently introduced support for multiple argument groups and multiple destination blocks in EDSC Expressions to implement conditional branches in EDSC. Conditional branches have two successors and three argument groups. The first group contains a single expression of i1 type that corresponds to the condition of the branch. The two following groups contain arguments of the two successors of the conditional branch instruction, in the same order as the successors. Expose this instruction to the C API and Python bindings. PiperOrigin-RevId: 235542768
* EDSC: support branch instructionsAlex Zinenko2019-03-293-70/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new implementation of blocks was designed to support blocks with arguments. More specifically, StmtBlock can be constructed with a list of Bindables that will be bound to block aguments upon construction. Leverage this functionality to implement branch instructions with arguments. This additionally requires the statement storage to have a list of successors, similarly to core IR operations. Becauase successor chains can form loops, we need a possibility to decouple block declaration, after which it becomes usable by branch instructions, from block body definition. This is achieved by creating an empty block and by resetting its body with a new list of instructions. Note that assigning a block from another block will not affect any instructions that may have designated this block as their successor (this behavior is necessary to make value-type semantics of EDSC types consistent). Combined, one can now write generators like EDSCContext context; Type indexType = ...; Bindable i(indexType), ii(indexType), zero(indexType), one(indexType); StmtBlock loopBlock({i}, {}); loopBlock.set({ii = i + one, Branch(loopBlock, {ii})}); MLIREmitter(&builder) .bindConstant<ConstantIndexOp>(zero, 0) .bindConstant<ConstantIndexOp>(one, 1) .emitStmt(Branch(loopBlock, {zero})); where the emitter will emit the statement and its successors, if present. PiperOrigin-RevId: 235541892
* EDSC printing: handle integer attributes with bitwidth > 64Alex Zinenko2019-03-291-2/+4
| | | | | | | | This came up in post-submit review. Use LLVM's support for outputting APInt values directly instead of obtaining a 64-bit integer value from APInt, which will not work for wider integers. PiperOrigin-RevId: 235531574
* Define a PassID class to use when defining a pass. This allows for the type ↵River Riddle2019-03-291-3/+1
| | | | | | used for the ID field to be self documenting. It also allows for the compiler to know the set alignment of the ID object, which is useful for storing pointer identifiers within llvm data structures. PiperOrigin-RevId: 235107957
* Exposed division and remainder operations in EDSCSergei Lebedev2019-03-292-12/+54
| | | | | | | | | | This change introduces three new operators in EDSC: Div (also exposed via Expr.__div__ aka /) -- floating-point division, FloorDiv and CeilDiv for flooring/ceiling index division. The lowering to LLVM will be implemented in b/124872679. PiperOrigin-RevId: 234963217
* EDSC: support call instructionsAlex Zinenko2019-03-293-5/+99
| | | | | | | | | | | | | | | | | | | | | | | | Introduce support for binding MLIR functions as constant expressions. Standard constant operation supports functions as possible constant values. Provide C APIs to look up existing named functions in an MLIR module and expose them to the Python bindings. Provide Python bindings to declare a function in an MLIR module without defining it and to add a definition given a function declaration. These declarations are useful when attempting to link MLIR modules with, e.g., the standard library. Introduce EDSC support for direct and indirect calls to other MLIR functions. Internally, an indirect call is always emitted to leverage existing support for delayed construction of MLIR Values using EDSC Exprs. If the expression is bound to a constant function (looked up or declared beforehand), MLIR constant folding will be able to replace an indirect call by a direct call. Currently, only zero- and one-result functions are supported since we don't have support for multi-valued expressions in EDSC. Expose function calling interface to Python bindings on expressions by defining a `__call__` function accepting a variable number of arguments. PiperOrigin-RevId: 234959444
* Fix unused errors in opt build.Jacques Pienaar2019-03-292-3/+4
| | | | PiperOrigin-RevId: 234841678
* EDSC: emit composed affine maps againAlex Zinenko2019-03-291-1/+13
| | | | | | | | | | | | | | | | The recent rework of MLIREmitter switched to using the generic call to `builder.createOperation` from OperationState instead of individual customized calls to `builder.create<>`. As a result, regular non-composed affine apply operations where emitted. Introduce a special case in Expr::build to always create composed affine maps instead, as it used to be the case before the rework. Such special-casing goes against the idea of EDSC generality and extensibility. Instead, we should consider declaring the composed form canonical for affine.apply operations and using the builder support for creating operations and canonicalizing them immediately (ongoing effort). PiperOrigin-RevId: 234790129
* EDSC: introduce min/max only usable inside for upper/lower bounds of a loopAlex Zinenko2019-03-291-8/+47
| | | | | | | | | | | | | | | | | | | Introduce a type-safe way of building a 'for' loop with max/min bounds in EDSC. Define new types MaxExpr and MinExpr in C++ EDSC API and expose them to Python bindings. Use values of these type to construct 'for' loops with max/min in newly introduced overloads of the `edsc::For` factory function. Note that in C APIs, we still must expose MaxMinFor as a different function because C has no overloads. Also note that MaxExpr and MinExpr do _not_ derive from Expr because they are not allowed to be used in a regular Expr context (which may produce `affine.apply` instructions not expecting `min` or `max`). Factory functions `Min` and `Max` in Python can be further overloaded to produce chains of comparisons and selects on non-index types. This is not trivial in C++ since overloaded functions cannot differ by the return type only (`MaxExpr` or `Expr`) and making `MaxExpr` derive from `Expr` defies the purpose of type-safe construction. PiperOrigin-RevId: 234786131
* EDSC: support multi-expression loop boundsAlex Zinenko2019-03-293-39/+147
| | | | | | | | | | | | | | MLIR supports 'for' loops with lower(upper) bound defined by taking a maximum(minimum) of a list of expressions, but does not have first-class affine constructs for the maximum(minimum). All these expressions must have affine provenance, similarly to a single-expression bound. Add support for constructing such loops using EDSC. The expression factory function is called `edsc::MaxMinFor` to (1) highlight that the maximum(minimum) operation is applied to the lower(upper) bound expressions and (2) differentiate it from a `edsc::For` that creates multiple perfectly nested loops (and should arguably be called `edsc::ForNest`). PiperOrigin-RevId: 234785996
* EDSC: create constants as expressionsAlex Zinenko2019-03-292-12/+48
| | | | | | | | | | | | | Introduce a functionality to create EDSC expressions from typed constants. This complements the current functionality that uses "unbound" expressions and binds them to a specific constant before emission. It comes in handy in cases where we want to check if something is a constant early during construciton rather than late during emission, for example multiplications and divisions in affine expressions. This is also consistent with MLIR vision of constants being defined by an operation (rather than being special kinds of values in the IR) by exposing this operation as EDSC expression. PiperOrigin-RevId: 234758020
* [EDSC] Fix Stmt::operator= and allow DimOp in For loopsNicolas Vasilache2019-03-293-3/+38
| | | | | | | | | | This CL fixes 2 recent issues with EDSCs: 1. the type of the LHS in Stmt::operator=(Expr rhs) should be the same as the (asserted unique) return type; 2. symbols coming from DimOp should be admissible as lower / upper bounds in For The relevant tests are added. PiperOrigin-RevId: 234750249
* NFC: Refactor the files related to passes.River Riddle2019-03-291-1/+1
| | | | | | | * PassRegistry is split into its own source file. * Pass related files are moved to a new library 'Pass'. PiperOrigin-RevId: 234705771
* [EDSC] Remove dead code in MLIREmitter.cppNicolas Vasilache2019-03-291-84/+0
| | | | | | | cl/234609882 made EDSCs typed on construction (instead of typed on emission). This CL cleans up some leftover dead code. PiperOrigin-RevId: 234627105
* EDSC: clean up type casting mechanismAlex Zinenko2019-03-292-53/+52
| | | | | | | | | | | | | | | | Originally, edsc::Expr had a long enum edsc::ExprKind with all supported types of operations. Recent Expr extensibility support removed the need to specify supported types in advance. Replace the no-longer-used blocks of enum values reserved for unary/binary/ternary/variadic expressions with simple values (it is still useful to know if an expression is, e.g., binary to access it through a simpler API). Furthermore, wrap string-comparison now used to identify specific ops into an `Expr::is_op<>` function template, that acts similarly to `Instruction::isa<>`. Introduce `{Unary,Binary,Ternary,Variadic}Expr::make<> ` function template that creates a Expression emitting the MLIR Op specified as template argument. PiperOrigin-RevId: 234612916
* EDSC: make Expr typed and extensibleAlex Zinenko2019-03-293-265/+418
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expose the result types of edsc::Expr, which are now stored for all types of Exprs and not only for the variadic ones. Require return types when an Expr is constructed, if it will ever have some. An empty return type list is interpreted as an Expr that does not create a value (e.g. `return` or `store`). Conceptually, all edss::Exprs are now typed, with the type being a (potentially empty) tuple of return types. Unbound expressions and Bindables must now be constructed with a specific type they will take. This makes EDSC less evidently type-polymorphic, but we can still write generic code such as Expr sumOfSquares(Expr lhs, Expr rhs) { return lhs * lhs + rhs * rhs; } and use it to construct different typed expressions as sumOfSquares(Bindable(IndexType::get(ctx)), Bindable(IndexType::get(ctx))); sumOfSquares(Bindable(FloatType::getF32(ctx)), Bindable(FloatType::getF32(ctx))); On the positive side, we get the following. 1. We can now perform type checking when constructing Exprs rather than during MLIR emission. Nevertheless, this is still duplicates the Op::verify() until we can factor out type checking from that. 2. MLIREmitter is significantly simplified. 3. ExprKind enum is only used for actual kinds of expressions. Data structures are converging with AbstractOperation, and the users can now create a VariadicExpr("canonical_op_name", {types}, {exprs}) for any operation, even an unregistered one without having to extend the enum and make pervasive changes to EDSCs. On the negative side, we get the following. 1. Typed bindables are more verbose, even in Python. 2. We lose the ability to do print debugging for higher-level EDSC abstractions that are implemented as multiple MLIR Ops, for example logical disjunction. This is the step 2/n towards making EDSC extensible. *** Move MLIR Op construction from MLIREmitter::emitExpr to Expr::build since Expr now has sufficient information to build itself. This is the step 3/n towards making EDSC extensible. Both of these strive to minimize the amount of irrelevant changes. In particular, this introduces more complex pretty-printing for affine and binary expression to make sure tests continue to pass. It also relies on string comparison to identify specific operations that an Expr produces. PiperOrigin-RevId: 234609882
* EDSC: introduce support for blocksAlex Zinenko2019-03-293-63/+144
| | | | | | | | | | | | | | | | | | | | | | | EDSC currently implement a block as a statement that is itself a list of statements. This suffers from two modeling problems: (1) these blocks are not addressable, i.e. one cannot create an instruction where thus constructed block is a successor; (2) they support block nesting, which is not supported by MLIR blocks. Furthermore, emitting such "compound statement" (misleadingly named `Block` in Python bindings) does not actually produce a new Block in the IR. Implement support for creating actual IR Blocks in EDSC. In particular, define a new StmtBlock EDSC class that is neither an Expr nor a Stmt but contains a list of Stmts. Additionally, StmtBlock may have (early-) typed arguments. These arguments are Bindable expressions that can be used inside the block. Provide two calls in the MLIREmitter, `emitBlock` that actually emits a new block and `emitBlockBody` that only emits the instructions contained in the block without creating a new block. In the latter case, the instructions must not use block arguments. Update Python bindings to make it clear when instruction emission happens without creating a new block. PiperOrigin-RevId: 234556474
* EDSC: properly construct FunctionTypesAlex Zinenko2019-03-291-1/+1
| | | | | | | | | | The existing implementation of makeFunctionType in EDSC contains a bug: the array of input types is overwritten using output types passed as arguments and the array of output types is never filled in. This leads to all sorts of incorrect memory behavior. Fill in the array of output types using the proper argument. PiperOrigin-RevId: 234177221
OpenPOWER on IntegriCloud