Comments (4)
It looks challenging to extend the tracking to support this specific case, although I may need to think further about it. Maybe we can also intercept replacements of tensor casts and walk up and down their use-def chains to see if we hit some tracked Linalg op that is affected, similarly to how we can see through casts when replacing a Linalg op with a cast.
The FoldTensorCastConsumerOp
pattern (don't be confused by the name, it is a pattern and not a folder) may or may not replace the linalg op. There is a control flow path where the op seems to be only cloned. I suppose the old op is expected to be DCE'd, at which point we would need to somehow match that the op being removed by DCE was previously "replaced" with something else.
The safest longer-term alternative IMO is to move towards "functional patterns" that we discussed and started introducing for some transformations. Such patterns return the updated "core" operation instead of just success/failure status so it is easy for external observers to update their state. This is not a foolproof solution though, some very generic canonicalization patterns may still find hacky ways of replacing tracked ops without adopting the "functional pattern" style. We can only assert aggressively against this and deal with the consequences when assertions fire, hoping that we have enough testing to deter whoever introducing such indiscriminate patterns from pushing them on everyone.
from iree-llvm-sandbox.
tensor casts and walk up and down their use-def chains to see if we hit some tracked Linalg op that is affected
Right that may work. When observing the replacement of an operation we may also consider deleted (DCE) and inserted adjacent operations and could then generate a replacement notification for them. In the example pattern, one LinalgOp is deleted and one LinalgOp is inserted so it can be seen as part of the CastOp replacement... It is less clear though what should happen if multiple LinalgOps are generated... We may just add replacement information for all of them and then let transformations filter the interesting ones.
I suppose the old op is expected to be DCE'd, at which point we would need to somehow match that the op being removed by DCE was previously "replaced" with something else.
After looking at the FoldTensorCastConsumerOp
pattern for some more time, I actually believe there is a bug if the linalgOp
has multiple results. In that case, both linalgOp
and newOp
will remain in the code. Writing the pattern with replaceOp
actually fixes the problem (https://reviews.llvm.org/D121369) if I am not mistaken.
The safest longer-term alternative IMO is to move towards "functional patterns"
I agree and it could well be that short-term we should just fix patterns that do not use replaceOp
properly.
PS Would it make sense to use Location information for the operation tracking. It may not help with this problem but it may help to debug or serialize the transformation history if an op is associated to its source code location but also to the location of the transform ops that have been applied.
from iree-llvm-sandbox.
When observing the replacement of an operation we may also consider deleted (DCE) and inserted adjacent operations and could then generate a replacement notification for them. In the example pattern, one LinalgOp is deleted and one LinalgOp is inserted so it can be seen as part of the CastOp replacement...
Adjacency is a weak relation here, I wouldn't build on that. We could indeed try to "match" a deletion and an insertion as a replacement, but I am wary of the tracking mechanism becoming excessively complex, the same way as dialect conversion that is no longer fully understood :) My thinking is that ultimately there is an operand being replaced by another value in the IR, so it should be possible to trace back from there. It's just that we don't have a hook for operand replacements.
I agree and it could well be that short-term we should just fix patterns that do not use replaceOp properly.
+1.
PS Would it make sense to use Location information for the operation tracking. It may not help with this problem but it may help to debug or serialize the transformation history if an op is associated to its source code location but also to the location of the transform ops that have been applied.
Most patterns just mindlessly copy the location info of the "main" matched op to all the new ops, so I expect this to be difficult. Some time ago (pre-Discourse, I think), I proposed to optionally append information about the patterns applied to the location info for debugging purposes. That is, the location info would contain the original location + "converted by PatternName in filename.cc:123". This was considered too expensive because this information is going to be stored in the context forever.
from iree-llvm-sandbox.
I am wary of the tracking mechanism becoming excessively complex
I agree matching adjacent operations is complicated and hard to follow for a user.
I proposed to optionally append information about the patterns applied to the location info for debugging purposes. That is, the location info would contain the original location + "converted by PatternName in filename.cc:123". This was considered too expensive because this information is going to be stored in the context forever.
Ah interesting! I was thinking about it from user perspective but I can see that it would add a significant amount of extra data that needs to be carried around...
from iree-llvm-sandbox.
Related Issues (20)
- Einseum-like spec for transposes HOT 1
- Failed to cancel out unrealized_conversion_cast HOT 2
- CI fails due to failure to install a Python dependency. HOT 1
- Support padding transpose in the transform dialect HOT 2
- PDL patterns HOT 1
- Segfault in some matmul cases HOT 8
- Error in PDL after Interpreter refactoring HOT 6
- Why the sandbox depends on Clang and its tools? HOT 3
- PadOp sometimes does not compose HOT 2
- PSA: renamed python_package -> python_packages
- PSA: Integration with IREE for multi-target and whole model compilation HOT 6
- Fuse & Tile & Pad produces possibly inefficient vector code. HOT 26
- Conv2D benchmark failed with DoubleTiling methods
- python.examples.matmul.test failed with ModuleNotFoundError
- Collaboration on data analytics workloads in MLIR HOT 12
- RFC: improve stacked commit flow
- [Substrait] Decide how to check for number of ops in module.
- [Substrait] Review construction of nested protobufs in `Export.cpp`
- Pass file name into SubstraitPB import.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iree-llvm-sandbox.