... | ... | @@ -8,8 +8,8 @@ |
|
|
- What about doing SA analysis in OccurAnal and calling `saTransform` from the Simplifier prior to inlining and unfolding? Here's what I had in mind:
|
|
|
1. OccurAnal populates `occ_static_args` field of `OccInfo` with a summary of which arguments a recursive function can be specialised to. (Pretty much done, modulo refactorings)
|
|
|
- It's weird to only look at StaticArgs info from RHSs, not from the let body.
|
|
|
2. `callSiteInline` should consider unfoldings of strong loop-breakers, if that unfolding has the new `UnfoldingSource` `SpecialiseStaticArg` (naming up for debate)
|
|
|
3. The simplifier calls out to `saTransform` or something similar to actually build the unfolding, looking at `occ_static_args` to see for which arguments it can specialise
|
|
|
2. `callSiteInline` should consider unfoldings of strong loop-breakers, if that unfolding has the new `UnfoldingSource` `SpecialiseStaticArg` (naming up for debate. Do we even need that?)
|
|
|
3. The simplifier calls out to `saTransform` or something similar to actually build the unfolding (do we need a new function à la `mkInlinableUnfolding` that builds the inlinable SAT'd thing?), looking at `occ_static_args` to see for which arguments it can specialise.
|
|
|
- I'm not dead set about where to put the `StaticArgs` information, which is basically a bit mask saying which arguments are static.
|
|
|
- I wonder if we could combine that with pre/post-inline-unconditionally. Currently, the occurrence info from the let body is completely zapped. I think we might disregard occurrences in the RHS for the annotation.
|
|
|
|
... | ... | |