WIP: Use constant propagation instead of Val in linalg #25303
Conversation
|
I think that’s right for now. Our heuristics are currently tied to inlining, so I think we can’t do much better right now. |
Would it be technically possible to make constant propagation a guarantee instead of an optimization? For this application here, I'm literally using it instead of dispatch and right now I'm heavily abusing |
|
Is using small, redirecting |
| if pivot == :none | ||
| return qrfactUnblocked!(A) | ||
| elseif pivot == :colnorm | ||
| return qrfactPivotedUnblocked!(A) |
There was a problem hiding this comment.
Transformations like these from explicit dispatch to dispatch-simulation-via-conditional seem a bit unfortunate. Perhaps some best-of-both-worlds approach exists, or could exist in the future? :)
There was a problem hiding this comment.
Perhaps dispatching to internal Val versions make the code cleaner (like #24960 (comment)).
Not sure if there are any drawbacks.
There was a problem hiding this comment.
Nice! Thanks :). (Interestingly, that approach dovetails nicely with Andy's comment.)
There was a problem hiding this comment.
I think the explicit list approach should be preferred Julian style for these methods
|
I have a local rebase of this PR, including some minor adjustments to avoid breaking the current interface. Not surprisingly, the |
|
Aha, if I force inlining more then tests pass, actually. Since I have it anyway, I'll open a new PR for discussion. |
This is my first attempt to remove the uses of
Valin the linear algebra code and instead rely on constant propagation. Currently, I think I have to use too make tricks to make inference work here so it would be great if @vtjnash could take a look. E.g. I'd like to get rid of these definitions and this@inlineannotations.