Fix a serious bug in roughMatchTcs
The roughMatchTcs function enables a quick definitely-no-match test in lookupInstEnv. Unfortunately, it didn't account for type families. This didn't matter when type families were flattened away, but now they aren't flattened it matters a lot. The fix is very easy. See INVARIANT in GHC.Core.InstEnv Note [ClsInst laziness and the rough-match fields] Fixes #19336 The change makes compiler perf worse on two very-type-family-heavy benchmarks, T9872{a,d}: T9872a(normal) ghc/alloc 2172536442.7 2216337648.0 +2.0% T9872d(normal) ghc/alloc 614584024.0 621081384.0 +1.1% (Everything else is 0.0% or at most 0.1%.) I think we just have to put up with this. Some cases were being wrongly filtered out by roughMatchTcs that might actually match, which could lead to false apartness checks. And it only affects these very type-family-heavy cases. Metric Increase: T9872a T9872d
Showing
- compiler/GHC/Core/FamInstEnv.hs 4 additions, 3 deletionscompiler/GHC/Core/FamInstEnv.hs
- compiler/GHC/Core/InstEnv.hs 18 additions, 29 deletionscompiler/GHC/Core/InstEnv.hs
- compiler/GHC/Core/Unify.hs 56 additions, 11 deletionscompiler/GHC/Core/Unify.hs
- compiler/GHC/Iface/Make.hs 15 additions, 17 deletionscompiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Rename.hs 5 additions, 5 deletionscompiler/GHC/Iface/Rename.hs
- compiler/GHC/IfaceToCore.hs 7 additions, 2 deletionscompiler/GHC/IfaceToCore.hs
- compiler/GHC/Tc/Instance/FunDeps.hs 3 additions, 3 deletionscompiler/GHC/Tc/Instance/FunDeps.hs
- compiler/GHC/Tc/Module.hs 2 additions, 1 deletioncompiler/GHC/Tc/Module.hs
- testsuite/tests/indexed-types/should_compile/T19336.hs 43 additions, 0 deletionstestsuite/tests/indexed-types/should_compile/T19336.hs
- testsuite/tests/indexed-types/should_compile/T19336.stderr 4 additions, 0 deletionstestsuite/tests/indexed-types/should_compile/T19336.stderr
- testsuite/tests/indexed-types/should_compile/all.T 1 addition, 0 deletionstestsuite/tests/indexed-types/should_compile/all.T
Loading
Please register or sign in to comment