Simon Peyton Jones pushed to branch wip/T26425 at Glasgow Haskell Compiler / GHC Commits: dfa7915a by Simon Peyton Jones at 2025-11-14T17:23:07+00:00 Comments only - - - - - 1 changed file: - compiler/GHC/Core/Opt/OccurAnal.hs Changes: ===================================== compiler/GHC/Core/Opt/OccurAnal.hs ===================================== @@ -659,13 +659,13 @@ through A, so it should have ManyOcc. Bear this case in mind! * In occ_env, the new (occ_join_points :: IdEnv OccInfoEnv) maps each in-scope non-recursive join point, such as `j` above, to a "zeroed form" of its RHS's usage details. The "zeroed form" - * has only occ_nested_lets in its domain (see (W5) below) + * has only occ_nested_lets in its domain (see (W4) below) * deletes ManyOccs * maps a OneOcc to OneOcc{ occ_n_br = 0 } In our example, assuming `v` is locally-let-bound, occ_join_points will be extended with [j :-> [v :-> OneOcc{occ_n_br=0}]] - See `addJoinPoint` and (W5) below. + See `addJoinPoint` and (W4) below. * At an occurrence of a join point, we do everything as normal, but add in the UsageDetails from the occ_join_points. See mkOneOcc. @@ -686,7 +686,7 @@ through A, so it should have ManyOcc. Bear this case in mind! from j's RHS. The only reason for `occ_nested_lets` is to reduce the size of the info - duplicate at each tail call; see (W5). It would sound to put *all* variables + duplicate at each tail call; see (W4). It would sound to put *all* variables into `occ_nested_lets`. Here are the consequences @@ -751,12 +751,7 @@ Wrinkles (W1) and (W2) are very similar to Note [Binder swap] (BS3). NB: this is just about efficiency: it is always safe /not/ to zap the occ_join_points. -(W4) What if the join point binding has a stable unfolding, or RULES? - They are just alternative right-hand sides, and at each call site we - will use only one of them. So again, we can use `combineJoinPointUDs` - to combine usage info from all these alternatives RHSs. - -(W5) Other things being equal, we want keep the OccInfoEnv stored in +(W4) Other things being equal, we want keep the OccInfoEnv stored in `occ_join_points` as small as possible, because it is /duplicated/ at /every occurrence/ of the join point. We really only want to include OccInfo for @@ -1002,6 +997,22 @@ of both functions, serving as a specification: Cyclic Recursive case: 'tagRecBinders' Acyclic Recursive case: 'adjustNonRecRhs' Non-recursive case: 'adjustNonRecRhs' + +Note [Unfoldings and RULES] +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For let-bindings we treat (stable) unfoldings and RULES as "alternative right hand +sides". That is, it's as if we had + f = case <hiatus> of + 1 -> <the-rhs> + 2 -> <the-stable-unfolding> + 3 -> <rhs of rule1> + 4 -> <rhs of rule2> +So we combine all these with `orUDs`. But actually it makes very +little difference whether we use `andUDs` or `orUDs` because of +Note [Occurrences in stable unfoldings and RULES]: occurrences in an unfolding +or RULE are treated as ManyOcc anyway. + +But NB that tail-call info is preserved so that we don't thereby lose join points. -} ------------------------------------------------------------------ @@ -1101,7 +1112,7 @@ occAnalNonRecRhs !env lvl imp_rule_edges mb_join bndr rhs , final_bndr_with_rules, final_rhs ) -- orUDs: Combine the RHS, (stable) unfolding, and RULES with orUDs - -- See (W4) of Note [Occurrence analysis for join points] + -- See Note [Unfoldings and RULES] where --------- Right hand side --------- -- For join points, set occ_encl to OccVanilla, via setTailCtxt. If we have @@ -3777,7 +3788,7 @@ andUDs = combineUsageDetailsWith (\_uniq -> andLocalOcc) orUDs = combineUsageDetailsWith (\_uniq -> orLocalOcc) combineJoinPointUDs :: OccEnv -> UsageDetails -> UsageDetails -> UsageDetails --- See (W5) in Note [Occurrence analysis for join points] +-- See (W4) in Note [Occurrence analysis for join points] combineJoinPointUDs (OccEnv { occ_nested_lets = nested_lets }) uds1 uds2 = combineUsageDetailsWith combine uds1 uds2 where View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/dfa7915ac104c4d94a003b7f274582f7... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/dfa7915ac104c4d94a003b7f274582f7... You're receiving this email because of your account on gitlab.haskell.org.