[GHC] #9688: Improve the interaction between CSE and the join point transformation

GHC ghc-devs at haskell.org
Wed Oct 15 21:32:31 UTC 2014


#9688: Improve the interaction between CSE and the join point transformation
-------------------------------------+-------------------------------------
              Reporter:  dfeuer      |            Owner:
                  Type:  feature     |           Status:  new
  request                            |        Milestone:
              Priority:  normal      |          Version:  7.9
             Component:  Compiler    |         Keywords:  CSE
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:
  performance bug                    |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 Replying to [comment:1 simonpj]:

 > Or, to put it another way, if the user wrote the above `Core`, complete
 with the local function `$j_s2BC`, would you expect it to be optimised?

 Probably so, but I don't really know. I think the basic concept is that we
 should let more information flow from the analysis of the main body into
 the analysis of `j`. I think these two steps would probably be a good
 start, although I imagine they could be refined. Of course, you may well
 know of seven fatal flaws in this approach.

 1. The simple one: If the value of a certain expression is always
 available when calling `j`, check if that expression is used in `j`; if
 so, pass it in. This is really just CSE, broadened to cross the boundary
 between the local function and the main body.

 2. The less simple one: If the scrutinee of a `case` in `j` has always
 been scrutinized before `j` is called, "trim" the branches to only the
 ones that are still possible, and then consider splitting `j` into its
 remaining branches. In the examples described above, one relevant `case`
 will be the outermost one in `j`, and that should pretty much always be
 merged upwards. Doing the same thing a few times will take care of the
 rest. I think this basically does what would have happened had `j` been
 inlined, but we actually ''know'' that we're getting something out of it.

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


More information about the ghc-tickets mailing list