Optimize named funs and fun-wrapped macros

[jhogberg]

This PR optimizes local fun usage by calling their implementation directly when possible, avoiding the creation of fun objects. This greatly speeds up macros that wrap their body in a fun, as well as "named funs" whose current implementation requires them to recreate themselves when used, even for something as simple as recursion.

%% make_fun2 + call_fun is now a simple call in the two funs below.

(fun(Name) -> io:format("Hello ~s!", [Name]) end)("Steve").

fun Seq(_Term, 0) -> [];
    Seq(Term, N) -> [Term | Seq(Term, N - 1)]
end.

https://bugs.erlang.org/browse/ERL-639

[josevalim]

@jhogberg this is very exciting as we could leverage this in a few places! 🎉

Just to clarify, will the optimization apply even if the function is used over multiple branches but never escaped? Take this nonsensical code just as an example:

Fun = fun(X) -> erlang:display({value, X}) end,
case SomeCondition of
  true -> Fun(Value), ok;
  false -> Fun(Value), error
end.

Follow up question, does it also apply for function captures such as fun some_private/2? If it does, I believe we need to make sure to inline the call to some_private/2 and not the generated intermediate function as HiPE wouldn't like if the intermediate function is called both directly and via an anonymous function.

[jhogberg]

Just to clarify, will the optimization apply even if the function is used over multiple branches but never escaped? Take this nonsensical code just as an example:

Yep. The optimization is completely turned off if it's escapes however, and it makes no attempt to delay fun creation until needed. This would be relatively straightforward to do but we haven't found a practical use for it yet and there are a few wrinkles where it could generate worse code.

Follow up question, does it also apply for function captures such as fun some_private/2? If it does, I believe we need to make sure to inline the call to some_private/2 and not the generated intermediate function as HiPE wouldn't like if the intermediate function is called both directly and via an anonymous function.

Yes, it applies to anything that creates local funs. I'll look into that, thanks for pointing it out!

[nox]

Cf. 42b87be which removes the abstraction @josevalim mentions but unfortunately breaks HiPE.

[nox]

11:56 <josevalim> nox: in case you want to link to the whole diff: master...nox:rm-reverse-eta-conversion

I was too lazy to find my own patch.

[jhogberg]

As far as I can tell the problems with HiPE would only occur when mixing make_fun and direct calls, which this pass avoids at the moment. Local funs always have their own intermediate function (even when wrapping another private function as below), and if the make_fun instruction disappears then there is no way for it to be referenced by both a fun and a regular call.

private() -> ok.
foo() ->
    A = fun private/0, %% '-foo/0-fun-0-'
    B = fun private/0, %% '-foo/0-fun-1-'
    Res = A(),
    Res = B().

Chances are I'm wrong though. Do you have any sneaky test cases to share from the last time this was an issue?

I've pushed an update that short-circuits direct calls to intermediate functions as it's a neat optimization in its own right, and we'll need it anyway when expanding this pass. Thanks again for pointing this out!

[nox]

Local funs always have their own intermediate function

That's what my patch tried to remove years ago, and HiPE was the only thing blocking that removal.

[jhogberg]

That's what my patch tried to remove years ago, and HiPE was the only thing blocking that removal.

Indeed. HiPE should add these intermediate functions when needed instead of imposing restrictions on the compiler, .beam may be a stable format but the generated code is not.