- User Since
- Jun 18 2016, 2:24 PM (222 w, 5 d)
Fri, Sep 18
I have several concerns with this as is. Blocking while OOO.
Wed, Sep 16
Thanks for driving this!
Mon, Sep 14
Tue, Sep 8
Mon, Sep 7
Sun, Sep 6
I have concerns about several aspects of what you are doing here. Blocking until I have time to review.
Wed, Sep 2
Thanks! This all looks really really good. I'm extremely busy over the next few days, but I'll try to give it a run over this weekend. Happy to see this coming to fruition.
Please resolve the clang-tidy and clang-format issues.
Tue, Sep 1
Mon, Aug 31
Please run clang-format, seems like there are a few issues sprinkled about.
Fri, Aug 28
Ah, I see that it already has an operator bool. Please still add the justification though. It's just as important to know why a change is happening as it is to know what is changing.
Please add justification in the description for why. Seems like this could be handled wherever Dialect is being constructed.
Thu, Aug 27
Fix accidental getSExtValue for unsigned
Wed, Aug 26
Please run clang-format.
Tue, Aug 25
The relationship between the op classes and registration feels under documented and easily error prone to new users. The fact that isa<AffineForOp>(op) will silently fail on an affine.for operation because the affine dialect isn't registered will likely feel wrong to many as an initial reaction. I'm not saying we should allow or encourage the use of the *Op classes when something is unregistered(we shouldn't), but it feels like we could make debugging/understanding a misconfiguration much easier; which if I recall is the original intention of the assert. E.g. as a bare bone hint, could we add a debug log that detects such situations and issues a message? e.g. something like: