- User Since
- Aug 20 2012, 11:51 AM (421 w, 6 d)
Fri, Sep 18
Fix variable name.
Thu, Sep 17
+1, added some verbiage to that effect
Fri, Sep 11
Thu, Sep 10
Wed, Sep 9
Tue, Sep 8
LGTM from my side
Wed, Sep 2
Tue, Sep 1
I still consider this feature naming (such as test case naming) very confusing. It's actually very simple to explain: "it allows a pass to call other passes". The name "dynamic pipeline" is very confusing -- like I'll need to re-explain to every new MLIR user that encounters the feature what the feature really is. "user: How can I call a pass from within my pass? mlir community: oh, use our dynamic pipeline feature. user: what is that? mlir community: it's a way to call a pass from within another pass; user: oh".
Mon, Aug 31
Now that this functionality has evolved, is there a better name to describe this functionality than "dynamic pipeline"? It's not associated with pipelines in any specific way, and it is not associated with dynamism per se (e.g. inliner could use a statically hardcoded simplification pipeline). Perhaps "recursive pass invocation"?
Fri, Aug 28
Using #ifdef's isn't great. Can we instead have a cl::opt and just use a regular if to control this. Then we can test it too.
Thu, Aug 27
Aug 20 2020
Also, can you update the commit description to include a description of the namespace changes?
Aug 10 2020
Is there anything about this specific to index type? Can this issue happen with any user-defined type?
Aug 7 2020
Jul 28 2020
Jul 27 2020
Can't we use shape.concat for this?
Jul 20 2020
What do you think about
%1 = shape.const_shape [1, 2, 3] %2 = shape.const_extent_tensor [4, 5, 6]
%1 = shape.const_shape [1, 2, 3] : !shape.shape %2 = shape.const_shape [4, 5, 6] : tensor<?xindex>
Jul 16 2020
Thanks for adding this!
It's kind of confusing that this is in llvm/utils while generate-test-checks.py is in mlir/utils. Is there a plan to reconcile this difference?
Jul 13 2020
Jul 7 2020
Jul 6 2020
Jun 26 2020
LGTM modulo incorporating our decision on the error case discussion from shape_eq.
LGTM modulo getting feedback for others on how to define the error cases.
It would be good to update https://mlir.llvm.org/docs/Dialects/LLVM/
Jun 25 2020
LGTM, modulo splitting into two ops and a nit.
(we could also use shape.eq to be the one for shapes, which is a bit shorter than shape.shape_eq; I personally like being a bit more explicit but it's up to you what feels best namingwise)
LGTM modulo splitting into two separate ops.
Jun 22 2020
Jun 19 2020
Jun 18 2020
Great! Thanks for these nicely factored patches!
LGTM modulo renaming of op (discussed in the dependent patch)
Jun 17 2020
Jun 16 2020
As per discussion today, this pattern is going to "fight" with what we are doing with IREE (and also npcomp). Can we reserve this pattern for the shape to std-with-descriptors lowering?
Jun 12 2020
Jun 11 2020
Can you add documentation for what happens in the case where the dimension index is out of bounds? Are we allowed to assume that doesn't happen?
Jun 10 2020
What is the invariant established by this pass that other passes can rely on? It seems that this pass is needed for correctness in many cases, not just optimization. So it needs to have a well-specified contract for later passes to rely on.
Thanks! For some reason I was assuming we already had this, so seeing it turned on is great!
Jun 9 2020
Jun 6 2020
Jun 5 2020
mlir/Dialect/Vector/CMakeLists.txt doesn't seem to need this?
@tpopp can you PTAL at this? Surely we aren't the first using DRR inside mlir core, and I didn't find evidence that this CMakeLists.txt annotation was needed for them. Wild guess, but perhaps we can put the ShapeCanonicalization.td in lib/ ?
Jun 4 2020
LGTM with one requested modification and a nit.