Closed arybczak closed 11 months ago
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, -fno-specialise-incoherents
. But it would be good to double-check with 9.8.1.
it would be good to double-check with 9.8.1.
@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 :disappointed:What do we do?