Fwd: Truffle CallNode API. Is it possible to keep the old inline API?

[Christian Humer]

Forwarded also to graal-dev mailing list.

---------- Forwarded message ----------
From: Christian Humer <christian.humer at gmail.com>
Date: Mon, Feb 10, 2014 at 5:24 PM
Subject: Re: Truffle CallNode API. Is it possible to keep the old inline
API?
To: Wei Zhang <ndrzmansn at gmail.com>


Hi Wei,

I definitely don't want to support both inlining APIs at the same time
because the old API would not support the changes that are currently in my
pipeline.
So I would need to support two completely different inlining heuristics at
the same time.

I took a look on the generator semantics of ZipPy and I also talked with
Christian Wimmer about it.
So I am already convinced that the transformations for generator calls are
required in order to optimize your use- cases.

>From the information I gathered, I want to propose two options on how I
think we can proceed in this matter:

1) On the way CallGeneratorNode#execute is implemented I assume that you do
not really want to use the inlining heuristic provided by the truffle
framework.
Instead you just want to inline always, right? Wouldn't it easier for you
to just always transform generator function calls and don't wait for the
inlining heuristic to say so?
In my opinion the generator transformation is not really inlining, its a
different more advanced concept and should also be treated this way.
If you want to perform this transformation just before compilation of a
method, we could also think of adding an API for getting notified just
before truffle compilation.
I would prefer if we could go that way.

2) I could provide you with an API to fully customize the behavior of
inlining in an individual CallNode.
The interface could look like this:
    public interface Inlining {
        RootNode inline(CallNode callNode);
    }

    public static final class DefaultInlining implements Inlining {
        public RootNode inline(CallNode callNode) {
            DefaultCallTarget defaultTarget = (DefaultCallTarget)
callNode.getCallTarget();
            return defaultTarget.getRootNode().inline();
        }
    }
For the generator transformations the inline implementation would perform
the required transformations on the parents of the CallNode.

Some other questions:
Can you undo generator call transformations? What if an generator call gets
inlined but the generator callsite gets megamorphic later on?
Besides CallGeneratorNode, the other call nodes can be migrated without
troubles?


- Christian Humer


On Mon, Feb 10, 2014 at 2:50 AM, Wei Zhang <ndrzmansn at gmail.com> wrote:

> Hi Christian,
>
> My problem is in CallGeneratorNode.
> When Truffle decide to inline a call to a generator function, ZipPy
> applies a transformation in the parent for loop that iterates on the
> returned generator.
> We forward the loop body into the inlined generator AST.
> It is an optimization targeting Python generators.
>
> As you pointed out, BuiltinIntrinsifer is currently somewhat experimental.
> It tries to intrinsify some builtin call patterns to simpler ZipPy
> nodes that are more efficient.
> It can also optimize away some generator semantics.
> The reason that we hook it up with inlining is because we want to
> apply it after the caller is inlined (or transformed).
>
> How difficult would it be for you to support two inline interfaces at
> the same time?
> Or does it make sense at all?
>
> Thanks for the fast response,
> /Wei
>
>
> On Sun, Feb 9, 2014 at 1:01 AM, Christian Humer
> <christian.humer at gmail.com> wrote:
> > Hi Wei,
> >
> > I had a very brief look at ZipPy calls and they seem to be implemented
> > nicely.
> > Do I guess correctly that your problems migrating is due to
> > BuiltinIntrinsifier?
> > Can you quickly outline the rationale behind it?
> > Can you point out other areas which got you into troubles?
> >
> > I will have an in depth look on them on Monday.
> >
> > Thx.
> >
> > - Christian Humer
> >
> >
> > On Sun, Feb 9, 2014 at 2:54 AM, Wei Zhang <ndrzmansn at gmail.com> wrote:
> >>
> >> Hi Christian Humer,
> >>
> >> I've been looking at the new CallNode API for a while now.
> >> I tried a couple of times to adopt it, but it hasn't been successful so
> >> far.
> >>
> >> The new inlining API does look cleaner and more compact.
> >> It makes more sense for the most part, but it requires a big change in
> >> ZipPy.
> >>
> >> One thing that ZipPy relies on in the old API is that one can
> >> customize the inlining logic.
> >> A Python level call Inlining could trigger some additional
> >> transformation in the caller's AST.
> >> In the new API, inlining is pretty much hidden from the caller.
> >>
> >> Admittedly there's always another way to achieve the same thing, but
> >> it would be nice to have the old API around at least before we can
> >> successfully migrate to the new one.
> >> Another option for me is to stop merging with Truffle until I figure
> >> everything out.
> >> But it is going to take a while before I can put my focus back on the
> >> new CallNode.
> >> And I know it is not healthy to fall behind for too long.
> >>
> >> I'm not sure how much it would affect you, but it is definitely making
> >> my life easier for the next month or so.
> >> Please let me know.
> >>
> >> Thanks,
> >>
> >> /Wei
> >
> >
>