-
Notifications
You must be signed in to change notification settings - Fork 24
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
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9411 seems to break us #488
Comments
Thanks for spotting this promptly! I brought up this worry speculatively at the time, but didn't get much traction. But if we have concrete evidence that the change regresses performance, let's file a GHC ticket asking for the change to be rethought (guarding it behind a flag would make sense to me). |
I've raised this upstream as https://gitlab.haskell.org/ghc/ghc/-/issues/23287 |
I believe this should now be resolved upstream as the problematic change is now guarded by a flag, |
@adamgundry does the CI suite passing on #499 mean that this is confirmed to not be an issue? |
Yes, with the GHC flag in place and CI passing I think there's nothing more to do here. |
Specifically, there's an incoherent instance of
AppendIndices
and if it's not optimized away (and it looks like after this patch it's not), everything crumbles.I checked the testsuite with GHC HEAD and 13 tests fail, all show presence of
$dAppendIndices
in Core that seem to inhibit further optimizations.The MR in question can't be cleanly reverted anymore, but when I did this:
All of these tests pass again, so I'm pretty sure it's the problem.
For the record, I'm not sure if the above diff is "safe" and I consider the GHC MR problematic.
GPlateInner
also has an incoherent instance. This one can't be removed 😞What do we do?
The text was updated successfully, but these errors were encountered: