Stuff on the local methods branch
maurizio.cimadamore at oracle.com
Mon Jan 6 23:47:16 UTC 2020
On 06/01/2020 23:39, Jesper Steen Møller wrote:
> Hi Maurizio
> On 7 Jan 2020, at 00.24, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>> I agree that LambdaToMethod was already complicated to begin with and now it gotten worse (I'm guilty of that, as I wrote the first hacky patch). Splitting local methods into their own phase seems like a good idea - initially I went for LambdaToMethod because this was a quick and dirty experiment and I wanted to reuse as much code as possible. That said, if we do split into a separate phase, we should try not to reinvent solution for problems we have already solved (e.g. find the set of captured entities). And my fear is that you need a lot of what the analyzer preprocessor currently do; I'd be happy to be proven wrong - if not, we could always find other ways to reuse the preprocessing info from multiple stages.
> I suppose I could refactor the “instanced”-style checks into abstract methods on the Context parts, but that will only solve part of the problem: Just like Lambda captures and lambda creation interleaves and need separate passes, so do local method captures and (recursive) local method calls. So it’s not really possible to do in two passes, but need something a separate pass for finding captures and then a separate one for the calls, or we’ll need a work-list or fixed-point type algorithm to deal with all the propagation.
> It’s just simpler to do in separate passes.
> I can try to put together a refactoring patch which adds one more pass for analysis and a separate one for but keeps the same 'Context' structure, or I can try to factor out the context-part and introduce a LocalLower pass altogether.
> Which style would you prefer?
I'll leave this to Srikanth who might already have been working on a
patch to support recursive local calls. I'm happy with whatever works -
even cut and paste stuff you need from one pass to another, and then we
can worry about how to reuse the pieces more elegantly later.
One thing to note is that it is not unusual for certain steps in the
pipeline to compute information and to hold them for a certain number of
subsequent step, until that info is no longer needed and is then
dropped. So, perhaps the analysis part which happens as part of
LambdaToMethod should be made more publicly available in the compiler
pipeline - e.g. maybe there are three steps:
Where the first sets up all the various capture contexts - the last
drops them. But maybe you don't want a 'context' that is general enough
to store info needed for both lambdas and local methods... in which case
no sharing is possible and we do need two separate analysis passes (and
only two pipeline steps - LambdaToMethod and TransLocalMethods)
> Oh, and who'll merge in the latest updates from default into the 'local-methods'-branch?
More information about the amber-dev