Stuff on the local methods branch

[Maurizio Cimadamore]

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:

CaptureAnalyzer
LambdaToMethod
TransLocalMethods

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)

Maurizio

>
> Oh, and who'll merge in the latest updates from default into the 'local-methods'-branch?
>
> -Jesper