Improve the handling of used-once stuff
Joachim and I are committing this onto a branch so that we can share it, but we expect to do a bit more work before merging it onto head. Nofib staus: - Most programs, no change - A few improve - A couple get worse (cacheprof, tak, rfib) Investigating the "get worse" set is what's holding up putting this on head. The major issue is this. Consider map (f g) ys where f's demand signature looks like f :: <L,C1(C1(U))> -> <L,U> -> . So 'f' is not saturated. What demand do we place on g? Answer C(C1(U)) That is, the inner C1 should stay, even though f is not saturated. I found that this made a significant difference in the demand signatures inferred in GHC.IO, which uses lots of higher-order exception handlers. I also had to add used-once demand signatures for some of the 'catch' primops, so that we know their handlers are only called once.
Showing
- compiler/basicTypes/BasicTypes.lhs 55 additions, 0 deletionscompiler/basicTypes/BasicTypes.lhs
- compiler/basicTypes/Demand.lhs 12 additions, 11 deletionscompiler/basicTypes/Demand.lhs
- compiler/basicTypes/Id.lhs 49 additions, 17 deletionscompiler/basicTypes/Id.lhs
- compiler/basicTypes/IdInfo.lhs 19 additions, 55 deletionscompiler/basicTypes/IdInfo.lhs
- compiler/basicTypes/MkId.lhs 2 additions, 1 deletioncompiler/basicTypes/MkId.lhs
- compiler/coreSyn/CoreArity.lhs 23 additions, 32 deletionscompiler/coreSyn/CoreArity.lhs
- compiler/coreSyn/PprCore.lhs 20 additions, 13 deletionscompiler/coreSyn/PprCore.lhs
- compiler/simplCore/OccurAnal.lhs 31 additions, 34 deletionscompiler/simplCore/OccurAnal.lhs
- compiler/simplCore/SetLevels.lhs 3 additions, 1 deletioncompiler/simplCore/SetLevels.lhs
- compiler/specialise/SpecConstr.lhs 1 addition, 1 deletioncompiler/specialise/SpecConstr.lhs
- compiler/stranal/WorkWrap.lhs 25 additions, 28 deletionscompiler/stranal/WorkWrap.lhs
- compiler/stranal/WwLib.lhs 33 additions, 31 deletionscompiler/stranal/WwLib.lhs
Loading
Please register or sign in to comment