User Details
- User Since
- Jan 9 2020, 1:48 AM (167 w, 5 d)
Wed, Mar 22
Thank you!
Address the comments.
Tue, Mar 21
Clean-up
address comments
Address the comments.
Mon, Mar 20
Tue, Mar 14
Thanks!
Mon, Mar 13
Sun, Mar 12
Address the comments.
Sat, Mar 11
Mon, Mar 6
update the test.
Thu, Mar 2
Wed, Mar 1
Tue, Feb 28
Is it equivalent to mlir-print-ir-after=pass-name ? https://mlir.llvm.org/docs/PassManagement/#ir-printing
Mon, Feb 27
Update
Sun, Feb 26
Feb 23 2023
Add a test.
Feb 22 2023
Feb 21 2023
Feb 20 2023
Feb 17 2023
I used
Feb 16 2023
Update tests
rebase
remove logging
Update.
Introduce mixed form.
Feb 15 2023
"Is anybody out there?"
Revert unchanged file.
Reconsidered :)
Update.
Feb 14 2023
Feb 1 2023
Jan 30 2023
Rebase
Jan 27 2023
Thank you!
Jan 26 2023
Jan 20 2023
Jan 19 2023
For instance developers often store models/IR in linalg format to be able to work in isolation of the front end. Those kind of changes forces them to regenerate models.
Jan 18 2023
Jan 17 2023
So, it looks like launching a sed command is churn. Comments are not churn, even though they take much more time and effort.
Interesting, and in this case we cannot infer the result type based on operands? Isn’t the result type always matching the outs tensors?
I think Mehdi has a good point about spending more time on design. I agree clean ups are nice, however I feel like the incremental breaking changes are causing the problem and we shouldn’t take those lightly. I believe there has been several syntax changes proposed to linalg ops in the recent past? Should we make sure we have a syntax that won’t need more change in the near future before make those changes? (Maybe it is worth a quick chat on discourse to make sure we address all the potential syntax problems at once and not continuously break users). What do you think?
@ThomasRaoux I would really like to do that, but linalg.generic allows the mixed case, when you have memrefs and tensors at the same time and some folks are using it for some reason.
Jan 16 2023
Jan 15 2023
Jan 14 2023
Why is this needed? DimOp always takes Value for the dimension index. There is no index attribute, which would allow to fold constants into the dimOp. With the current DimOp it is easier to call getValueOrCreateConstantIndexOp when DimOp::build is called.