Opened 2 years ago

Last modified 2 years ago

#13224 new bug

Rules and join points

Reported by: lukemaurer Owned by: lukemaurer
Priority: normal Milestone:
Component: Compiler Version: 8.0.1
Keywords: JoinPoints Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


From Note [Rules and join points] in OccurAnal:

Things get fiddly with rules. Suppose we have:

  let j :: Int -> Int
      j y = 2 * y
      k :: Int -> Int -> Int
      {-# RULES "SPEC k 0" k 0 = j #-}
      k x y = x + 2 * y
  in ...

Now suppose that both j and k appear only as saturated tail calls in the body. Thus we would like to make them both join points. The rule complicates matters, though, as its RHS has an unapplied occurrence of j. However, if we were to eta-expand the rule, all would be well:

  {-# RULES "SPEC k 0" forall a. k 0 a = j a #-}

So conceivably we could notice that a potential join point would have an "undersaturated" rule and account for it. This would mean we could make something that's been specialised a join point, for instance. But local bindings are rarely specialised, and being overly cautious about rules only costs us anything when, for some j:

  • Before specialisation, j has non-tail calls, so it can't be a join point.
  • During specialisation, j gets specialised and thus acquires rules.
  • Sometime afterward, the non-tail calls to j disappear (as dead code, say), and so now j could become a join point.

This appears to be very rare in practice. TODO Perhaps we should gather statistics to be sure.

Change History (1)

comment:1 Changed 2 years ago by simonpj

In the case where j is a join-point before specialisation, are we sure it'll stay a join-point afterwards?

Note: See TracTickets for help on using tickets.