#4962: Dead code fed to CorePrep because RULEs keep it alive spuriously
---------------------------------+------------------------------------------
    Reporter:  batterseapower    |        Owner:                         
        Type:  bug               |       Status:  new                    
    Priority:  normal            |    Milestone:                         
   Component:  Compiler          |      Version:  7.0.1                  
    Keywords:                    |     Testcase:                         
   Blockedby:                    |   Difficulty:                         
          Os:  Unknown/Multiple  |     Blocking:                         
Architecture:  Unknown/Multiple  |      Failure:  Runtime performance bug
---------------------------------+------------------------------------------

Comment(by simonpj):

 But in principle if this definition appears in the interface file, it may
 be inlined, and then the local RULES may spring into action, no?  What you
 say about dropping local rules is true if the defn doesn't appear in the
 interface file.

 Moreover, even if it ''does'' appear in the interface file, there is no
 need to feed those unused local let-bindings down through `CorePrep` and
 the code generator.

 Hmm.  Consider a defn that does appear in an interface file. We tidy it,
 and should presumably include RULES on local let-bindings.  Now I suppose
 we want to walk over it again, dropping the RULES (and INLINE pragmas
 incidentally) and doing occurrence analysis.

 The easy way to do this is as follows.
  * Don't change `CoreTidy`
  * In `CorePrep` dump all RULES and INLINE pragmas, whether top-level or
 nested.  (Remember, interface files see the result of `CoreTidy`;
 `CorePrep` is the start of the codegen pipeline.)
  * Do occurrence analysis on the result oc `CorePrep`.  This step will
 drop all dead code.  NB that a top-level `Id` f mentioned only in a RULE
 for an externally-visible `Id` g will itself be marked as externally-
 visible by `CoreTidy`.  And the occurrence ahalyser should keep all such
 things.  (Need to check that.)

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4962#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to