Truffle CallNode API

[Christian Humer]

Hi Stefan,

executeEvaluated should just create an arguments object and then call the
CallNode#call method.
Please have another look at my patch. There I've already tried to implement
executeEvaluated as I think it should be for the BinaryMessageNode.

I also encourage you to take another look at the current version of the
simple language.
In the last two weeks it received a lot of attention thanks to Christian
Wimmer.


- Christian Humer


On Fri, Jan 31, 2014 at 12:35 AM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Christian:
>
> Just a brief note after having a quick look at your patch.
> I am currently relying on methods like:
>
> public abstract Object executeEvaluated(final VirtualFrame frame, final
> Object receiver, Object argument);
>
> and similar for the Unary/Binary/Ternary/KeywordMessageNodes.
> I use them to pass the values that have been determined in the
> CachedSendNode to the actual methods.
> Guess, I'll need to rethink that as well, most likely together with the
> rest of the send nodes.
> (Or I hack these methods into CallNode until I find a better solution just
> to make it work for the moment.)
>
> Well, I'll try to find a solution.
>
> Thanks for your help again!
> Stefan
>
> On 30 Jan 2014, at 23:43, Christian Humer <christian.humer at gmail.com>
> wrote:
>
> > Hi Stefan,
> >
> > Sorry for not giving you a pre-notice on that change. Should have done
> that.
> > I've attached a small patch (off list) for the BinarySend on how I think
> you can try to align your interpreter to the new CallNode. (I've not run
> the patch, nor does it compile, nor did I change the other send types, so
> no guarantees ;-) )
> >
> > CallNode is supposed to be used as a child node in your inline cache
> whenever a CallTarget is considered constant. So it is not considered to be
> subclassed (and that is an important part of the concept). If you
> (CallNode#inline) or the heuristic decides to inline a node it now
> internally copies to RootNode with RootNode#inline and then calls the
> RootNode instead of the CallTarget. Yes you are right, this introduces some
> more nodes to your AST, which you could previously get rid of by replacing
> the complete inline cache entry with the inlined version of the function.
> However Truffle/Graal is smart enough to still have the same performance in
> the compiled version of the function (the allocation of the arguments
> object and boxing goes away).
> >
> > The node is there to hand a certain kind of control over calls to the
> Truffle Framework. On the long term I want to realize not just inlining but
> also things like tail recursion optimization on a Truffle level with that
> node.
> >
> > I wanted to support inlining without the need of implementing the
> interfaces InlinableCallNode and InlinedCallSite. Which resulted in
> implementing the same interpreter profiling (callcount) for inlining
> separately for every guest language. This means if there was a change to
> the inlining heuristic that required additional profiling we had to add
> that in all the guest languages that do inlining. With the CallNode I can
> now define the interpreter profiling myself that is required for the
> heuristic. The guest language implementor does not have to worry about that
> anymore. (he can still tune the parameters)
> >
> > I also wanted to hide inlining mostly from the guest language
> implementor. So inlining should be an additional optimization that truffle
> performs but it should have no effect on the public tree structure. In that
> way the guest language implementor does not need to worry if he is in an
> inlined node or not by default. However if he wants to he can use
> RootNode#getParentInlinedCall() as well as CallNode#getInlinedRoot() to
> access the inlined trees as well. But that is usually the exception (I
> think).
> >
> > Please feel free to ask further questions.
> >
> > - Christian Humer
> >
> >
> > On Thu, Jan 30, 2014 at 9:53 PM, Stefan Marr <java at stefan-marr.de>
> wrote:
> > Hi Christian:
> >
> > On 29 Jan 2014, at 22:09, Christian Humer <christian.humer at gmail.com>
> wrote:
> >
> > > I just updated the Truffle Inlining API with a more robust solution
> (will
> > > get pushed to openjdk this night).
> > > I removed the old API namely the following interfaces
> InlinableCallSite and
> > > InlinedCallSite.
> > > As a replacement for those classes you should now use a new class
> CallNode.
> > > This class is already a Node and can directly be used as such inside
> of an
> > > polymorphic function inline cache.
> > > For further information on how to use it please see
> SLDirectDispatchNode
> > > and the javadoc in the CallNode class.
> >
> > I still haven't looked for an alternative solution to my explicit
> Unary/Binary/Ternary/Keyword nodes, which facilitate specialization of
> things like add. But this change seems to be incompatible with my solution,
> because I am not really supposed to subclass CallNode, right? At least I am
> guessing that reading the factory methods.
> > Or would it be fine to have custom subclasses?
> >
> > Thanks
> > Stefan
> >
> > --
> > Stefan Marr
> > INRIA Lille - Nord Europe
> > http://stefan-marr.de/research/
> >
> >
> >
> >
> > <callnode_binary.patch>
>
> --
> Stefan Marr
> INRIA Lille - Nord Europe
> http://stefan-marr.de/research/
>
>
>
>