[Git][ghc/ghc][wip/sjakobi/T27115] 2 commits: WIP
Simon Jakobi pushed to branch wip/sjakobi/T27115 at Glasgow Haskell Compiler / GHC Commits: ac1cb6b0 by Simon Jakobi at 2026-03-28T11:24:57+01:00 WIP - - - - - 0b9b38ed by Simon Jakobi at 2026-03-28T11:35:53+01:00 WIP - - - - - 1 changed file: - compiler/GHC/Types/Demand.hs Changes: ===================================== compiler/GHC/Types/Demand.hs ===================================== @@ -2206,10 +2206,10 @@ demand, used for signature inference. Therefore we place a top demand on all arguments. For example, the demand transformer described by the demand signature - DmdSig (DmdType {x -> <1L>} <A><1P(L,L)>) + DmdSig (DmdType <A><1P(L,L)>{x->1L}) says that when the function is applied to two arguments, it -unleashes demand 1L on the free var x, A on the first arg, -and 1P(L,L) on the second. +unleashes demand A on the first arg, 1P(L,L) on the second, +and 1L on the free var x. If this same function is applied to one arg, all we can say is that it uses x with 1L, and its arg with demand 1P(L,L). @@ -2229,10 +2229,10 @@ was evaluated. Here's an example: The abstract transformer (let's call it F_e) of the if expression (let's call it e) would transform an incoming (undersaturated!) head sub-demand A -into a demand type like {x-><1L>,y-><L>}<L>. In pictures: +into a demand type like <L>{x->1L,y->L}. In pictures: SubDemand ---F_e---> DmdType - <A> {x-><1L>,y-><L>}<L> + <A> <L>{x->1L,y->L} Let's assume that the demand transformers we compute for an expression are correct wrt. to some concrete semantics for Core. How do demand signatures fit @@ -2240,7 +2240,7 @@ in? They are strange beasts, given that they come with strict rules when to it's sound to unleash them. Fortunately, we can formalise the rules with Galois connections. Consider -f's strictness signature, {}<1L><L>. It's a single-point approximation of +f's strictness signature, <1L><L>. It's a single-point approximation of the actual abstract transformer of f's RHS for arity 2. So, what happens is that we abstract *once more* from the abstract domain we already are in, replacing the incoming Demand by a simple lattice with two elements denoting incoming @@ -2260,8 +2260,8 @@ With and F_f being the abstract transformer of f's RHS and f_f being the abstracted abstract transformer computable from our demand signature simply by - f_f(>=2) = {}<1L><L> - f_f(<2) = multDmdType C_0N {}<1L><L> + f_f(>=2) = <1L><L> + f_f(<2) = multDmdType C_0N <1L><L> where multDmdType makes a proper top element out of the given demand type. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5a9a121b8cc3b57fca6675421097c56adc369609...0b9b38ed6831e8a6e216d4a8ea620cfd27aeb9f4 -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5a9a121b8cc3b57fca6675421097c56adc369609...0b9b38ed6831e8a6e216d4a8ea620cfd27aeb9f4 You're receiving this email because of your account on gitlab.haskell.org.
participants (1)
-
Simon Jakobi (@sjakobi2)