-
Notifications
You must be signed in to change notification settings - Fork 5
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
ssa self logic doesn't work with list member #61
Comments
I think its incredibly tricky. I think some sort variable name interpolation to make using explicit attribute ergonomic would probably be a better solution |
Hmm, yea thought about this some more. It seems that in sequential we don't actually support real python lists, it's more just syntax sugar on a fixed size array (since the call method can't dynamically change the list contents). And so, if we're using that restriction, then we can "unroll" the array into scalar values as a pass before entering SSA. |
Or we can just provide a symbol interpolation feature so the user can effectively do the same thing (again, this would avoid the issue about requiring the user to manage this conversion themselves) |
Not sure if this would help, but I think Torch has a similar issue and resolves it by using a custom list. https://pytorch.org/docs/stable/generated/torch.nn.ModuleList.html |
Yea I think we could define a syntax layer that allows you to use a list abstraction inside init (e.g. for generator code that builds/appends to a list based on some parameter), then inside call we can assume the list size is fixed (i.e. the user can only index the list to refer to elements), so at that point we can "desugar" the list into elements (for the simplicity of the subsequent pass logic). So the special list object can be used differently in different stages (or perhaps another way to view it is inside call the user has a restricted view of the list, which could be defined by a custom list type). There might be some concern about code size explosion, but I think for the common case it should be fine. |
From @cdonovick
|
This code:
produces
notice the shift input is ignored in the rewritten call
If instead we use explicit attributes for each list member, it works as expected.
produces
@cdonovick I can look into implementing this, but have any guidance on whether/how we could support this?
The text was updated successfully, but these errors were encountered: