Opened 22 months ago

Last modified 22 months ago

#11602 new bug

Exponential behaviour in typeKind, unifyTys etc

Reported by: simonpj Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

In Trac #11371 Bartosz found some very suspicious performance behaviour. Specifically:

  • See comment 42 of #11371, which says that liftCoMatch and promoteCoercion is responsible for a significant fraction of all compiler allocation. Why so expensive? Especially since only used from OptCoercion.
  • There are two comments in Unify saying
    ty_co_match_app menv subst ty1a ty1b co2a co2b
      = do { -- TODO (RAE): Remove this exponential behavior.
             subst1 <- ty_co_match menv subst  ki1a ki2a ki_ki_co ki_ki_co
    

and

unify_ty_app ty1a ty1b ty2a ty2b
  = do { -- TODO (RAE): Remove this exponential behavior.
         let ki1a = typeKind ty1a
             ki2a = typeKind ty2a
       ; unify_ty ki1a ki2a (mkNomReflCo liftedTypeKind)

NB: ty_co_match_app is also called from liftCoMatch.

Change History (2)

comment:1 Changed 22 months ago by simonpj

Bartosz says: The hottest chain goes like this: promoteCoercion -> eqType -> cmpType -> cmpTypeX -> typeKind -> piResultTys.

comment:2 Changed 22 months ago by niteria

This is a profile that I got recently on T5030: P101.

promoteCoercionU1 is the SCC I added here

Note: See TracTickets for help on using tickets.