-
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
Odd variable/buffer names in conceptual_stmt. #7924
Comments
Re: See also the pinned issue "Halide development roadmap": #5055 . Quoting the key summary:
|
I think it's injected here: https://github.com/halide/Halide/blob/main/src/FuseGPUThreadLoops.cpp#L480 and I think the reason is that when allocations are hoisted to the gpu block level, they might have name collisions with other allocations that now have the same scope, and this numbering makes that impossible. |
Aha, that sounds reasonable. Any idea why the rfactor() intermediate
|
So it should be allowed to only add those numbers in case of collisions? Maybe one day I'll feel like trying to implement that cheap change with a |
I can't assign people (or add labels, or ask for reviews or anything), but I'd assign myself if I could. |
I get a lot of .0, .1, .2, .4, ... as suffixes in buffer names in the conceptual stmt, which would be nice if it can be cleaned up. Haven't taken the time to figure out where they come from.
A few examples:
When using
rfactor()
for a summation over a 2D RDom:A bit of everything:
Where in the above screenshot, the red arrows are all the places where the buffers have the suffix, yet the producer/consumer name is clean, as indicated by the green arrows.
The text was updated successfully, but these errors were encountered: