How to do AST inlining of method calls?

[Stefan Marr]

Hi:

I am experimenting with AST inlining in the TruffleSOM implementation and would like to know what the suggested best practices are.

I started to inline monomorphic message sends in order to avoid issues with mega-morphic send sites typically found when evaluating blocks (lambdas).

Now I am wondering how far that inlining logic should be pushed.
I attempted to just duplicate the relevant AST subtree and leave the nodes themselves more or less untouched.
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.

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.


private Object executeInlined(final PackedFrame caller, final Object rcvr,
        final Object[] args) {
      final VirtualFrame frame = frameFactory.create(
          inlinedMethod.getFrameDescriptor(), caller, new Arguments(rcvr, args));

      final FrameOnStackMarker marker = Misc.initializeFrame(frame.materialize(),
          inlinedMethod.getArgumentSlots(),
          universe.nilObject);
      return Misc.sendSiteExecution(marker, frame, methodBody); // this or any of the `executeGeneric(VirtualFrame)` calls in it are problematic
}

So, now the question for me is whether I should avoid the frame creation in the first place, and instead should try to rewrite all nodes that rely on frame access, or whether there is another common solution in other Truffle languages to such issues.

Thanks
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