How to do AST inlining of method calls?

[Stefan Marr]

Hi:

On 11 Sep 2013, at 02:31, Andreas Woess <andreas.woess at jku.at> wrote:

> On 11.09.2013 01:20, Stefan Marr wrote:
>> Specifically, this means, I still rely on a frame to be constructed in a new InlinedMonomorphicMessageNode, which I introduced.
>> This approach allows me to preserve the semantics of having a frame, and with it access to the same Smalltalk local variables as previously, even so the AST nodes are inlined in the monomorphic all site. Another problem this design solves is the catching of the same control flow exceptions as the method node that got replaced. Especially, the non-local return still needs to be treated correctly, I think, even with inlining.
> This is the correct approach. Note that you should duplicate the tree in
> its uninitialized state (e.g. in the constructor of the method root node
> and keep a copy there) so that the inlined tree specializes for that
> particular call.

Right, that's what I do. Currently, the only specialization is for monomorphic and polymorphic sends.
And the copying of tree nodes for message sends will create an uninitialized message send node.


>> Currently, my main issue with this naive approach is that I still need to create a VirtualFrame object.
>> This is possible with the frame factory given to the inline(.) method of the InlinableCallSite interface, but it causes problems with the Graal/Truffle compiler. The VerifyFrameDoesNotEscapePhase causes issues, because it sees the frame creation and complains about the fact that the new frame is given to a method call. The executeInlined(..) method below is the relevant fragment.
> Again, this is this the right way. You should get a stack trace with the
> approximate location of the problem.

After experimenting more with this, and trying to understand what the issue is, I start to belief that the heuristic encoded in VerifyFrameDoesNotEscapePhase is just to simple. After removing the check for passing the frame on to a method, the benchmarks run to completion. So, I have the feeling (but without being very confident) that I use the frame classes in a more or less correct way.

I am wondering whether there could just be an annotation that tells the check in VerifyFrameDoesNotEscapePhase that a frame passed to a certain method is not problematic?
The reason why I think that the heuristic is too simple is that method call boundaries are a to strong constrained. Since not all calls are inlined in the graph, the check becomes restrictively conservative. I experimented with just duplicating code to give the check more information, but as soon as I get to a truly polymeric send site, I still get into trouble…

I wonder why such a simple issue is not problematic in the other Truffle-based languages being implemented. Could I annotate the frame creation with something that marks it as unproblematic?


For others interested in the code for inlining methods, the following commit should be the most relevant piece:  https://github.com/smarr/TruffleSOM/commit/1edba8692fd0a0ffe78510f45597c6f8a8a6cadf
The cloning of nodes is introduced here: https://github.com/smarr/TruffleSOM/commit/851549ac9d04315a755a1851a002e7b1bd96e55c

Best regards
Stefan


-- 
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525