#4081: Strict constructor fields inspected in loop
---------------------------------+------------------------------------------
    Reporter:  rl                |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:                         
   Component:  Compiler          |      Version:  6.13                   
    Keywords:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Testcase:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------

Comment(by simonpj):

 We could arrange that w/w transformed the case to add
 {{{
   case m_ajy of I# m' -> ...
 }}}
 just inside the T.S match.  As things stand today, this case would be
 eliminated by the "drop redundant seqs" transformation.  But perhaps that
 transformation is too eager.  It drops a case that looks like
 {{{
    case x of { C y1..yn -> body }
 }}}
 where the y1..yn are not mentioned in body, and x is known to be
 evaluated.  See
 {{{
 --      2. Eliminate the case if scrutinee is evaluated
 }}}
 in `Simplify`.

 This is correct, but it might be better to 'retain' the case if there are
 any binders y1..yn, at least until the end of simplification (`CorePrep`
 perhaps).  Then we can drop it.  That would deal with this particular case
 at least.

 Another opportunity that we do not exploit right now is strictness in a
 free variable.  Consier
 {{{
 f x = letrec g y = if x>0 then ..g y'....
                    else ...g y''...
       in (g y1, g y2)
 }}}
 If we lambda-lifted, we'd evaluate 'x' just once; as things stand we do it
 each time.  A modification to the w/w transform might handle this.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4081#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to