As a first step, represent statically known passing constraint as a
true op and remove assuming ops that rely on only true_witness ops.
Use a fold.
We might not want this pattern always. For example, if we have a pass that does code motion on islands, this canonicalization can prematurely remove the island which will make that pass unable to operate properly. Let's hold off on adding it until we have a compelling use case.
This will segfault if getDefiningOp returns null.
I don't think that TableGen is buying us much here. I prefer loose C++ patterns since they are easier to debug and understand.
Can you make this test have less op surface area? Maybe use an unknown op to capture the witness (or return the witness) instead of having the shape.assuming?
Easier to understand is arguable: this can be a matter of getting used to it, easier to debug is an infra issue which should be fixed if any.
C++ pattern aren't ideal because we can't manipulate them statically: even if DRR is far from perfect, at least it is declarative.
I split this commit up into smaller pieces.
I don't find this a compelling argument. Not all code will be in islands and these islands are for the purpose of making code conditional on some assertion. If it's statically known that the assertion is not a problem and the island cannot be removed, then the island is being misused for another purpose and blocking possible compiler optimizations.
Changed to opPosition as the rewriter starts where the op is.
I'm going to leave as tablegen. I'm not a big fan of almost all tablegen patterns for LLVM but am going along with what the infrastructure implies it wants.
I split these into one for each canonicalization.