-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Refine effects for getfield corner cases #48203
Conversation
I've pushed some tiny related commits to this PR, since otherwise, this'll just end up conflicting with each other. Should all be straightforward. |
I will push some changes to fix test failures. |
a90405f
to
043440b
Compare
thanks |
I'm concerned about that GC root issue in llvmpasses. I also saw something similar locally on a branch that included these changes. Is that currently a known issue on master or is that new on this branch? In either case, we should try to capture it in rr and see what the missing root is. |
Maybe it's the issue that Jameson pointed out about #47994 (esp. #47994 (comment))? |
Assertions are enabled, so if that were the issue, i think we'd have seen the assertion in #48089. |
(unrelated to the GC issue) So it seems like the remaining test failures (in |
The test in compiler/inline is fine, it's just getting some extra junk basic blocks:
The test should be updated to test what it actually wants to know (two getfield calls, one tuple call, no other calls). |
We were already able to essentially fold this away, but we were incorrectly tainting :consistency.
Okay, just confirmed that LLVM optimizes those junks away. The remaining ones are related to |
When all fields are known initialized syntactically, we do not need to test whether accessing the fields will give an UndefRef. We only need to check for the fields that are not syntactically known to be initialized. As a result, this commit improves `:consistent`-cy of `getfield` call, which is better in general but leads to inference/inlining accuracy regression in some edge cases because now irinterp is enabled on more frames. There are two regressions, but we are fine with them so we modify the test cases: - inlining regression: irinterp ends up some extra junk basic blocks, that LLVM can optimize away down the road. - inference regressions: these regressions are all related to the `MustAlias` lattice extension, which was added for JET's use case especially and not enabled in base yet. Since JET doesn't enable irinterp, this commit marks the regressed cases as broken.
Like other mutable allocation consistency here is flow-dependent.
043440b
to
26b0588
Compare
Okay, fixed up all the failed cases. Should be good to go. |
Follow up #48203. See the added test cases for the purpose of this commit.
Follow up #48203. See the added test cases for the purpose of this commit.
See individual commits.