| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
as it is no longer necessary now that all instructions are operations.
PiperOrigin-RevId: 232356323
|
|
|
|
|
|
|
|
| |
The generic form may be more desirable even when there is a custom form
specified so add option to enable emitting it. This also exposes a current bug
when round tripping constant with function attribute.
PiperOrigin-RevId: 232350712
|
|
|
|
|
|
| |
lib/Transforms.
PiperOrigin-RevId: 232322771
|
|
|
|
|
|
| |
the Instruction variants.
PiperOrigin-RevId: 232322030
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loops), (2) take into account fast memory space capacity and lower 'dmaDepth'
to fit, (3) add location information for debug info / errors
- change dma-generate pass to work on blocks of instructions (start/end
iterators) instead of 'for' loops; complete TODOs - allows DMA generation for
straightline blocks of operation instructions interspersed b/w loops
- take into account fast memory capacity: check whether memory footprint fits
in fastMemoryCapacity parameter, and recurse/lower the depth at which DMA
generation is performed until it does fit in the provided memory
- add location information to MemRefRegion; any insufficient fast memory
capacity errors or debug info w.r.t dma generation shows location information
- allow DMA generation pass to be instantiated with a fast memory capacity
option (besides command line flag)
- change getMemRefRegion to return unique_ptr's
- change getMemRefFootprintBytes to work on a 'Block' instead of 'ForInst'
- other helper methods; add postDomInstFilter option for
replaceAllMemRefUsesWith; drop forInst->walkOps, add Block::walkOps methods
Eg. output
$ mlir-opt -dma-generate -dma-fast-mem-capacity=1 /tmp/single.mlir
/tmp/single.mlir:9:13: error: Total size of all DMA buffers' for this block exceeds fast memory capacity
for %i3 = (d0) -> (d0)(%i1) to (d0) -> (d0 + 32)(%i1) {
^
$ mlir-opt -debug-only=dma-generate -dma-generate -dma-fast-mem-capacity=400 /tmp/single.mlir
/tmp/single.mlir:9:13: note: 8 KiB of DMA buffers in fast memory space for this block
for %i3 = (d0) -> (d0)(%i1) to (d0) -> (d0 + 32)(%i1) {
PiperOrigin-RevId: 232297044
|
|
|
|
|
|
| |
references to OperationInst in the /include, /AffineOps, and lib/Analysis.
PiperOrigin-RevId: 232199262
|
|
|
|
|
|
| |
still exists as a forward declaration and will be removed incrementally in a set of followup cleanup patches.
PiperOrigin-RevId: 232198540
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and ElementsAttr
These attribute kinds are different from the rest in the sense that their types are defined
in MLIR's type hierarchy and we can build constant op out of them.
By defining this middle-level base class, we have a unified way to test and query the type
of these attributes, which will be useful when constructing constant ops of various dialects.
This CL also added asserts to reject non-NumericAttr in constant op's build() method.
PiperOrigin-RevId: 232188178
|
|
|
|
| |
PiperOrigin-RevId: 232159334
|
|
|
|
|
|
| |
mechanical, i.e. changing usages of ForInst to OpPointer<AffineForOp>. An important difference is that upon construction an AffineForOp no longer automatically creates the body and induction variable. To generate the body/iv, 'createBody' can be called on an AffineForOp with no body.
PiperOrigin-RevId: 232060516
|
|
|
|
|
|
|
|
| |
- getTerminator() on a block can return nullptr; moreover, blocks that are improperly
constructed/transformed by utilities/passes may not have terminators even for the
top-level blocks
PiperOrigin-RevId: 232025963
|
|
|
|
|
|
| |
operands. This class stores operands in a similar way to SmallVector except for two key differences. The first is the inline storage, which is a trailing objects array. The second is that being able to dynamically resize the operand list is optional. This means that we can enable the cases where operations need to change the number of operands after construction without losing the spatial locality benefits of the common case (operation instructions / non-control flow instructions with a lifetime fixed number of operands).
PiperOrigin-RevId: 231910497
|
|
|
|
|
|
| |
Replace all instances of IfInst with AffineIfOp and delete IfInst.
PiperOrigin-RevId: 231342063
|
|
|
|
| |
PiperOrigin-RevId: 231327161
|
|
|
|
|
|
| |
instances of IfInst with AffineIfOp and delete IfInst.
PiperOrigin-RevId: 231318632
|
|
|
|
|
|
| |
works with it, and updating the g3docs.
PiperOrigin-RevId: 231120927
|
|
|
|
|
|
| |
instead of the ForInst itself. This is a necessary step in converting ForInst into an operation.
PiperOrigin-RevId: 231064139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Addresses b/122486036
This CL addresses some leftover crumbs in AffineMap and IntegerSet by removing
the Null method and cleaning up the constructors.
As the ::Null uses were tracked down, opportunities appeared to untangle some
of the Parsing logic and make it explicit where AffineMap/IntegerSet have
ambiguous syntax. Previously, ambiguous cases were hidden behind the implicit
pointer values of AffineMap* and IntegerSet* that were passed as function
parameters. Depending the values of those pointers one of 3 behaviors could
occur.
This parsing logic convolution is one of the rare cases where I would advocate
for code duplication. The more proper fix would be to make the syntax
unambiguous or to allow some lookahead.
PiperOrigin-RevId: 231058512
|
|
|
|
| |
PiperOrigin-RevId: 231014261
|
|
|
|
|
|
|
| |
Use `-mlir-pretty-debuginfo` if the user wants line breaks between different callsite lines.
The print results before and after this CL are shown in the tests.
PiperOrigin-RevId: 231013812
|
|
|
|
|
|
| |
block list for verbose printing.
PiperOrigin-RevId: 230951462
|
|
|
|
|
|
|
|
| |
improves the performance of dominance queries, which are used quite often within the compiler(especially within the verifier).
This reduced the execution time of a few internal tests from ~2 minutes to ~4 seconds.
PiperOrigin-RevId: 230819723
|
|
|
|
|
|
|
|
|
|
|
| |
canonicalizations of operations. The ultimate important user of this is
going to be a funcBuilder->foldOrCreate<YourOp>(...) API, but for now it
is just a more convenient way to write certain classes of canonicalizations
(see the change in StandardOps.cpp).
NFC.
PiperOrigin-RevId: 230770021
|
|
|
|
|
|
| |
remapping successor block operands of terminator operations. We define a new BlockAndValueMapping class to simplify mapping between cloned values.
PiperOrigin-RevId: 230768759
|
|
|
|
|
|
| |
will allow for truly round tripping debug locations given that we assign locations while parsing IR.
PiperOrigin-RevId: 230627191
|
|
|
|
| |
PiperOrigin-RevId: 230605756
|
|
|
|
| |
PiperOrigin-RevId: 230592860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Location printing is currently behind a command line flag "mlir-print-debuginfo", we can rethink this when we have a pass for stripping debug info or when we have support for printer flags.
Example inline notation:
trailing-location ::= 'loc' '(' location ')'
// FileLineCol Location.
%1 = "foo"() : () -> i1 loc("mysource.cc":10:8)
// Name Location
return loc("foo")
// CallSite Location
return loc(callsite("foo" at "mysource.cc":19:9))
// Fused Location
/// Without metadata
func @inline_notation() loc(fused["foo", "mysource.cc":10:8])
/// With metadata
return loc(fused<"myPass">["foo", "foo2"])
// Unknown location.
return loc(unknown)
Locations are currently only printed with inline notation at the line of each instruction. Further work is needed to allow for reference notation, e.g:
...
return loc 1
}
...
loc 1 = "source.cc":10:1
PiperOrigin-RevId: 230587621
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
- ForInst::walkOps will also be used in an upcoming CL (cl/229438679); better to have
this instead of deriving from the InstWalker
PiperOrigin-RevId: 230413820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Fix FloatAttr type inconsistency in conversion from tf.FusedBatchNorm to TFLite ops
We used to compose the splat tensor out of the scalar epsilon attribute by using the
type of the variance operand. However, the epsilon attribute may have a different
bitwidth than the one in the variance operand. So it ends up we were creating
inconsistent types within the FloatAttr itself.
2) Fix SplatElementsAttr type inconsistency in AnnotateInputArrays
We need to create the zero-valued attribute according to the type provided as the
command-line arguments.
3) Concretize the result type of tf.Shape constant folding test case
Currently the resultant constant is created by the constant folding harness, using
the result type of the original op as the constant's result type. That can be
a different type than the constant's internal DenseElementsAttr.
PiperOrigin-RevId: 230244665
|
|
|
|
|
|
|
|
| |
- print multiplication by -1 as unary negate; expressions like s0 * -1, d0 * -1
+ d1 will now appear as -s0, -d0 + d1 resp.
- a minor cleanup while on printAffineExprInternal
PiperOrigin-RevId: 230222151
|
|
|
|
|
|
| |
element of a constant. This also adds a 'getValue' function to DenseElementsAttr and SparseElementsAttr to get the element at a constant index.
PiperOrigin-RevId: 230098938
|
|
|
|
|
|
| |
converting the double value to the target type semantics. A comment is added to discourage the use of this method for non simple constants. The new handling also removes the direct use of the float constructor for APFloat to avoid runtime float cast asan errors.
PiperOrigin-RevId: 230014696
|
|
|
|
|
|
| |
attributes.
PiperOrigin-RevId: 229973134
|
|
|
|
|
|
| |
of attributes and rerwite DenseElementsAttr::writeBits/readBits to handle non uniform bitwidths. This fixes asan failures that happen when using non uniform bitwidths.
PiperOrigin-RevId: 229815107
|
|
|
|
|
|
|
|
|
|
| |
The operand and result types of binary ops are not necessarily the
same. For those binary ops, we cannot print in the short-form assembly.
Enhance impl:::printBinaryOp to consider operand and result types
to select which assembly form to use.
PiperOrigin-RevId: 229608142
|
|
|
|
|
|
| |
each context a unique TypeUniquer instance.
PiperOrigin-RevId: 229460053
|
|
|
|
|
|
| |
- readability changes
PiperOrigin-RevId: 229443430
|
|
|
|
|
|
| |
instead of converting to the KeyTy. This allows for handling cases where the KeyTy does not provide an equality operator on itself.
PiperOrigin-RevId: 229423249
|
|
|
|
| |
PiperOrigin-RevId: 229290802
|
|
|
|
|
|
| |
KeyTy. This will simplify the cases where a type can be constructed, and need to be verified, in multiple ways.
PiperOrigin-RevId: 229279000
|
|
|
|
|
|
| |
references held by those blocks when dropping references for the instruction.
PiperOrigin-RevId: 229278667
|
|
|
|
|
|
|
| |
This is to keep consistent with other TableGen generated builders
so that we can also use this builder in TableGen rules.
PiperOrigin-RevId: 229244630
|
|
|
|
|
|
| |
branch conditions.
PiperOrigin-RevId: 229242007
|
|
|
|
|
|
|
|
| |
of greater than 64 bits.
DenseElementAttr currently does not support value bitwidths of > 64. This can result in asan failures and crashes when trying to invoke DenseElementsAttr::writeBits/DenseElementsAttr::readBits.
PiperOrigin-RevId: 229241125
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 229167099
|
|
|
|
|
|
|
|
| |
This CL is the 6th and last on the path to simplifying AffineMap composition.
This removes `AffineValueMap::forwardSubstitutions` and replaces it by simple
calls to `fullyComposeAffineMapAndOperands`.
PiperOrigin-RevId: 228962580
|
|
|
|
| |
PiperOrigin-RevId: 228926113
|