Opened 4 years ago

Closed 4 years ago

#11163 closed bug (fixed)

New exhaustiveness checker breaks T5642

Reported by: bgamari Owned by: gkaracha
Priority: high Milestone: 8.0.1
Component: Compiler Version: 7.10.2
Keywords: pattern checker, PatternMatchWarnings Cc: gkaracha
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

The new exhaustiveness checker drastically increases compile time of the T5642 testcase. From the profile it appears that a great deal of time is being spent evaluating Check.mkPmId.occname,

COST CENTRE                 MODULE       %time %alloc

mkPmId.occname              Check         73.7   16.9
mkOneConFull                Check          3.4   10.2
deSugar                     HscMain        2.8   14.8
mkOneConFull.arguments      Check          2.5    5.5
pmTraverse                  Check          1.6    0.8
mkOneConFull.subst1         Check          1.5    5.9
wrapK.go                    Check          1.5    5.9
cMatcher                    Check          1.2    2.7
canEvVar                    TcCanonical    1.0    3.4

Change History (6)

comment:1 Changed 4 years ago by bgamari

Owner: set to gkaracha

comment:2 Changed 4 years ago by Ben Gamari <ben@…>

In dc33e4c/ghc:

T5642 is broken

This appears to be due to the new exhaustiveness checker. See #11163.

comment:3 Changed 4 years ago by bgamari

Keywords: pattern checker added

comment:4 Changed 4 years ago by simonpj

Keywords: PatternMatchWarnings added

comment:5 Changed 4 years ago by gkaracha

After merging Phab:D1795, I checked again the situation with T5642:

With the old pattern match checker the deviation (for bytes allocated) for #5642 was 196.8%. With the current HEAD it is 222.3%, yet this increase is not only due to the new checker. Disabling coverage checking for the test gives deviation 212.0%, which means that only 10.3% is due to the new checker.

Concerning this 10.3%, the module uses the generics library and function to :: Rep a x -> a has 100 clauses, all with nested patterns. Most importantly, Rep is a type family, which means that the new checker goes the extra mile to ensure they are all well-typed. Hence, this 10.3% is quite reasonable (the old pattern match checker was --in most cases-- faster because it did not take into account types).

comment:6 Changed 4 years ago by gkaracha

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.