- User Since
- Dec 20 2019, 9:16 PM (108 w, 4 d)
This makes sense to me, and I'm trying to remember why I didn't do it originally (I remember considering the new approach but can't remember why I avoided it). I think I was aliasing the prohibition that regular pybind classes cannot further modify new with these not actually being pybind classes.
LGTM modulo comments. I vaguely recall this kind of target sniffing having caused me problems in the past but I can't remember the details. Doing the same as llvm, sgtm.
Mon, Jan 17
Ugh, ugh. Let's definitely ask the pybind folks after landing. I'm also wondering if this part should just be implemented with the python c API. The concept is simpler than the code.
Fri, Jan 14
This is gross - I'm sorry it had caused some hard debugging for you, but thank you.
Thu, Jan 13
Wed, Jan 12
Tue, Jan 11
Thank you River - this is much nicer than I thought it would be.
Sun, Jan 9
Thanks - lg modulo comments.
Wed, Jan 5
Excellent!! Thanks! I think that leaves us only with a hidden dependency on all dialects registration and execution engine that, if fixed, would dramatically reduce downstream build time and distribution size.
Tue, Jan 4
Nice improvement - thanks! (and sorry for review latency)
I believe the plan is record is to remove the ops from this dialect, so just exposing types here is preferred (as you have it).
I wish I could uninvent those types, but they've been stable for a long time, and there are repeated requests to have access to them - so no objection to this API surface increase.
Mon, Jan 3
Update type metadata.
Sun, Jan 2
Good catch - and sorry: I am not sure what I was thinking with those. As-is, we hold the GIL all the time, so they are fine to remove. I think I was attempting to make it future proof for cases where we may want to release the GIL for long running operations (i.e. transforms, etc). These cases represent re-entrancy where it would need to be managed carefully. Clearly wrong as-is, though so fine to remove.
Fri, Dec 31
You'll then need to enable that option when building the examples project test (which uses these and is likely why the bots are failing).
There are people relying on this. Can you just disable this option by default until we find something better? That way they can still opt in.
Thu, Dec 30
Thu, Dec 23
Filed issue: https://github.com/llvm/llvm-project/issues/52862 for clarification. I don't like not understanding action-at-a-distance things like this and maybe the author can recall.
Dec 13 2021
Remove restriction on DropUnitDims.
Nov 29 2021
Feel free to comment post-submit (and/or submit more fixes).
Add pyi bindings.
Comments and rebase.
Thanks for the fix (by way of fixing the shapes so that we could remove the fallback to unverified printing). I was able to line things up on my screen to side by side review, but for the future, as Mehdi says: an NFC split followed by a fix to the few impacted test cases would be better (or the other way around).
Nov 28 2021
Nov 24 2021
Nov 19 2021
Nov 14 2021