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
[WGSL] Overload resolution shouldn't eagerly promote variables #13017
[WGSL] Overload resolution shouldn't eagerly promote variables #13017
Conversation
EWS run on previous version of this PR (hash db176cb) |
db176cb
to
561afa9
Compare
EWS run on previous version of this PR (hash 561afa9) |
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.
561afa9
to
37d466f
Compare
EWS run on current version of this PR (hash 37d466f) |
https://bugs.webkit.org/show_bug.cgi?id=255771 rdar://108361197 Reviewed by Mike Wyrzykowski. During overload resolution, when trying to assign a type to a variable we check whether it satisifies the variable's constraints. In order to satisfy a constraint we might need to promote the type being assigned to the variable. The example from the tests is when the variable requires a concrete type but we are assigning an abstract type to it. Originally, we would promote the type as soon as we assigned it to the variable, but that is not always correct. The promotion algorithm will pick the cheapest conversion, in this case it would promote an AbstractInt to an i32, which is a valid conversion. However, later we observe that the same variable is also being unified with an u32, which was also a valid conversion for the original type (AbstractInt), but since we already promoted the variable to i32, we can no longer unify the variable with u32, since we can't unify i32 and u32. The solution is faily straightforward though: we still reject types that don't satisfy the constraints, but hold off on promoting the type until we materialize the variable after determining that a given overload is a viable candidate. This guarantees that there will be a suitable promotion that will satisfy the constraints, but we delay choosing which type we'll promote to until we have looked at all arguments. * Source/WebGPU/WGSL/Overload.cpp: (WGSL::OverloadResolver::materialize const): (WGSL::OverloadResolver::assign): * Source/WebGPU/WGSL/tests/valid/overload.wgsl: Canonical link: https://commits.webkit.org/263355@main
37d466f
to
5186c24
Compare
Committed 263355@main (5186c24): https://commits.webkit.org/263355@main Reviewed commits have been landed. Closing PR #13017 and removing active labels. |
5186c24
37d466f
π§ͺ wpe-wk2π§ͺ gtk-wk2π§ͺ mac-AS-debug-wk2