Implement CallArity analysis
This analysis finds out if a let-bound expression with lower manifest arity than type arity is always called with more arguments, as in that case eta-expansion is allowed and often viable. The analysis is very much tailored towards the code generated when foldl is implemented via foldr; without this analysis doing so would be a very bad idea! There are other ways to improve foldr/builder-fusion to cope with foldl, if any of these are implemented then this step can probably be moved to -O2 to save some compilation times. The current impact of adding this phase is just below +2% (measured running GHC's "make").
Showing
- compiler/basicTypes/Id.lhs 10 additions, 1 deletioncompiler/basicTypes/Id.lhs
- compiler/basicTypes/IdInfo.lhs 9 additions, 3 deletionscompiler/basicTypes/IdInfo.lhs
- compiler/coreSyn/CoreArity.lhs 1 addition, 2 deletionscompiler/coreSyn/CoreArity.lhs
- compiler/coreSyn/PprCore.lhs 8 additions, 4 deletionscompiler/coreSyn/PprCore.lhs
- compiler/ghc.cabal.in 1 addition, 0 deletionscompiler/ghc.cabal.in
- compiler/main/DynFlags.hs 5 additions, 0 deletionscompiler/main/DynFlags.hs
- compiler/simplCore/CallArity.hs 459 additions, 0 deletionscompiler/simplCore/CallArity.hs
- compiler/simplCore/CoreMonad.lhs 3 additions, 0 deletionscompiler/simplCore/CoreMonad.lhs
- compiler/simplCore/SimplCore.lhs 10 additions, 0 deletionscompiler/simplCore/SimplCore.lhs
- compiler/simplCore/SimplUtils.lhs 3 additions, 1 deletioncompiler/simplCore/SimplUtils.lhs
Loading
Please register or sign in to comment