| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
PiperOrigin-RevId: 286906740
|
|
|
|
|
|
| |
Closes tensorflow/mlir#177
PiperOrigin-RevId: 275692653
|
|
|
|
| |
PiperOrigin-RevId: 264482571
|
|
|
|
| |
PiperOrigin-RevId: 264193915
|
|
|
|
|
|
|
|
|
|
|
| |
affine.load/store/dma_start/dma_wait.
In most places, this is just a name change (with the exception of affine.dma_start swapping the operand positions of its tag memref and num_elements operands).
Significant code changes occur here:
*) Vectorization: LoopAnalysis.cpp, Vectorize.cpp
*) Affine Transforms: Transforms/Utils/Utils.cpp
PiperOrigin-RevId: 256395088
|
|
|
|
|
|
|
|
| |
These are only required in .h files to disambiguate between C and C++ header files.
--
PiperOrigin-RevId: 248219135
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247789235
|
|
|
|
|
|
|
|
| |
Fix a GCC warning
--
PiperOrigin-RevId: 247670176
|
|
|
|
|
|
|
|
| |
and rename walkPostOrder to walk.
--
PiperOrigin-RevId: 241965239
|
|
|
|
|
|
| |
Now that we have a dependence analysis, we can check that loops are indeed parallel and make vectorization correct.
PiperOrigin-RevId: 240682727
|
|
|
|
| |
PiperOrigin-RevId: 240569775
|
|
|
|
|
|
| |
*Op classes. This is a net reduction by almost 400LOC.
PiperOrigin-RevId: 239972443
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
references to OperationInst in the /include, /AffineOps, and lib/Analysis.
PiperOrigin-RevId: 232199262
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL introduces a hotfix post refactoring of NestedMatchers:
- fix uninitialized read to skip
- avoid bumpptr allocating with 0 elements
Interestingly the latter issue only surfaced in fastbuild mode with no-san and
manifested itself by a SIGILL. All other combinations that were tried failed to
reproduce the issue (dbg, opt, fastbuild with asan)
PiperOrigin-RevId: 231787642
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A performance issue was reported due to the usage of NestedMatcher in
ComposeAffineMaps. The main culprit was the ubiquitous copies that were
occuring when appending even a single element in `matchOne`.
This CL generally simplifies the implementation and removes one level of indirection by getting rid of
auxiliary storage as well as simplifying the API.
The users of the API are updated accordingly.
The implementation was tested on a heavily unrolled example with
ComposeAffineMaps and is now close in performance with an implementation based
on stateless InstWalker.
As a reminder, the whole ComposeAffineMaps pass is slated to disappear but the bug report was very useful as a stress test for NestedMatchers.
Lastly, the following cleanups reported by @aminim were addressed:
1. make NestedPatternContext scoped within runFunction rather than at the Pass level. This was caused by a previous misunderstanding of Pass lifetime;
2. use defensive assertions in the constructor of NestedPatternContext to make it clear a unique such locally scoped context is allowed to exist.
PiperOrigin-RevId: 231781279
|
|
|
|
|
|
| |
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
|
|
This CL follows up on a memory leak issue related to SmallVector growth that
escapes the BumpPtrAllocator.
The fix is to properly use ArrayRef and placement new to define away the
issue.
The following renaming is also applied:
1. MLFunctionMatcher -> NestedPattern
2. MLFunctionMatches -> NestedMatch
As a consequence all allocations are now guaranteed to live on the BumpPtrAllocator.
PiperOrigin-RevId: 231047766
|