Opened 9 years ago

Closed 7 years ago

#2831 closed bug (fixed)

Floated error expressions get poor strictness, leaving bad arity

Reported by: simonpj Owned by:
Priority: low Milestone: 7.0.1
Component: Compiler Version: 6.10.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

GHC is careful to ensure that

  f = \x.  case x of 
               [] -> error "urk"
               (y:ys) -> \z. <blah>

gets arity 2. It does this by giving error an infinite arity. But if the error call is floated out by full laziness thus

  lvl = error "urk"
  f = \x.  case x of 
               [] -> lvl
               (y:ys) -> \z. <blah>

it's a bit less obvious. But it's ok: the strictness analyser disovers that lvl diverges.

Alas, if f is marked INLINE, there's a danger that this does not happen properly, perhaps because the inlining happens after strictness analysis. Or because the error message involves the parameter:

  {-# INLINE f #-}
  f = \x. case x of
            [] -> error ("urk" ++ x)
            (y:ys) -> \z. <blah>

I think I've seen this in connection with array indexing (where the error case is the index out of bounds error). I'm recording this ticket so that I don't forget about this problem.

Change History (6)

comment:1 Changed 9 years ago by igloo

Milestone: 6.10 branch

comment:2 Changed 9 years ago by igloo

Milestone: 6.10 branch6.12 branch

comment:3 Changed 8 years ago by simonmar

Type of failure: Runtime performance bug

comment:4 Changed 8 years ago by igloo

Milestone: 6.12 branch6.12.3

comment:5 Changed 7 years ago by igloo

Milestone: 6.12.36.14.1
Priority: normallow

comment:6 Changed 7 years ago by simonpj

Resolution: fixed
Status: newclosed

Works fine with new inline story. The inline template is what you write, but the optimised form is fine.

Note: See TracTickets for help on using tickets.