-
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
Explicitly name the allocgroups on GPU schedules "allocgroup__..." #7883
Conversation
Is this ready to merge? (It's still marked as a draft). IMO even if a better solution comes along for very long merged allocation names we should merge it because it's a small PR that makes a positive change. |
Okay, go ahead! Marked as ready. |
Wait, actually... I discovered today that it still prepends "allocgroup_" even if the group is of size 1. I'll see if I can squeeze that out. |
…ains more than 1 allocation prepend the prefix.
92339f2
to
d9559db
Compare
Okay, I did it. I was a little surprised by the double layered hierarchy of grouping: |
Here's the reason for the double-layered hierarchy (IIRC): Sets of allocations with non-overlapping lifetime go into an AllocGroup, the size of which is the max across all the allocations in the group. Then those groups are concatenated into a single big allocation, the size of which is the sum across all the groups. |
Are we merging this? It's ready, if you ask me. 😄 |
…alide#7883) * 50cents readibility improvement to allocgroups on GPU schedules. * Improve allocation group prefix: only if the alloc group cluster contains more than 1 allocation prepend the prefix.
I was flabbergasted when inspecting the schedule using the conceptual_stmt of a GPU schedule. The loads and stores didn't make any sense to me. After digging through the lowering passes, I found out about the AllocGroups and the clustering in the
FuseGPUThreadLoops
pass.I prepended
"allocgroup_"
to the name of the Allocate node now, to make that clearer in the Stmt.I still have another concern with this, and don't know what to do about it. After working on a schedule for a while, the names of these AllocGroups get really long, like:
Which is anything but readable, especially in code like this:
I was thinking that it might be useful to just rename the allocations to
allocgroup_0
,allocgroup_1
, etc... and somehow keep the list of shared allocations in this allocation group as meta information of theAllocate
IR node, which can then be used to produce Stmt code with comments on what is contained within this grouped alloc.