-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Teach unrolling to exploit conditions in enclosing ifs #7969
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a similar optimization can be done in VectorizeLoops, but I guess it's far less common (useful) for vectorize to be used like this in schedules.
Maybe a better design is to have a pass that forces loops that need to have a constant extent to have a constant extent and run it prior to unrolling and vectorization. Those two passes run back-to-back anyway. |
Changed to that strategy. As a bonus this now permits vectorization of loops with a constant upper bound on their extent, by injecting a predicate, just like with unrolling. This means you can write slightly simpler schedules when you have something compute_at a GuardWithIf loop. Whereas previously you had to say:
Now you can just say:
This makes GuardWithIf schedules a little more similar to ShiftInwards or RoundUp schedules. |
Adding release notes tag so we remember to mention that you can now vectorize loops that merely have a constant upper bound on their extent. |
Ohhh, that's really nice! |
Ready to land? |
* Teach unrolling to exploit conditions in enclosing ifs Fixes halide#7968 * Handle vectorization as well * Remove unused usings * Add missing print
Fixes #7968
This also changes the interface to simplify() to accept a vector of boolean Exprs that can be assumed to be true, which is a change I've been meaning to make for a while. The simplifier supports it internally, but it wasn't exposed in the API.