-
Notifications
You must be signed in to change notification settings - Fork 162
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
"A unique tuple element of return value of function ... is aliased to some other tuple component" ICE #1949
Comments
This is the other end of #803. We can either relax internal type checking a bit more or actually solve it properly this time. |
athas
added a commit
that referenced
this issue
Jun 9, 2023
This is a proper fix of #803 (see also discussion in #1949). The main issue we address is that in the core language representation of a function originally returning [](t,t), the two constituent arrays cannot possibly alias. This fix complicates the core language, but in a principled way. Each return type of a function is now accompanied by two lists: * Which function parameters the result may alias. * Which other results the result may alias. For simplicity these are integer lists, interpreted as indexes. This is quite trivial to check in the core typechecker and to propagate in alias analysis. The main challenge is to infer the lists based on the source language types, as the source language is not so precise about aliasing. I don't feel that my current solution is fully principled, and I'm worried that I might have gotten it wrong (which will manifest as compiler crashes - not as quietly invalid code generation). There is also a remaining outstanding question in that we have no conscious policy on whether a core language function is allowed to return something that aliases a global variable. We do not permit this in the source language. We currently do allow this in the core, but I think the only case where it will currently happen is for entry points that are non-functions in the source program. Fixes #1949.
razetime
pushed a commit
to razetime/futhark
that referenced
this issue
Jul 16, 2023
This is a proper fix of diku-dk#803 (see also discussion in diku-dk#1949). The main issue we address is that in the core language representation of a function originally returning [](t,t), the two constituent arrays cannot possibly alias. This fix complicates the core language, but in a principled way. Each return type of a function is now accompanied by two lists: * Which function parameters the result may alias. * Which other results the result may alias. For simplicity these are integer lists, interpreted as indexes. This is quite trivial to check in the core typechecker and to propagate in alias analysis. The main challenge is to infer the lists based on the source language types, as the source language is not so precise about aliasing. I don't feel that my current solution is fully principled, and I'm worried that I might have gotten it wrong (which will manifest as compiler crashes - not as quietly invalid code generation). There is also a remaining outstanding question in that we have no conscious policy on whether a core language function is allowed to return something that aliases a global variable. We do not permit this in the source language. We currently do allow this in the core, but I think the only case where it will currently happen is for entry points that are non-functions in the source program. Fixes diku-dk#1949.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This bug occurs on
0.24.3
and 889eeb9 (latest commit):Error:
The text was updated successfully, but these errors were encountered: