Calling internal functions - foo::bar() ?

[Thomas Lindgren]

--- Bjorn Gustavsson <bjorn@REDACTED> wrote:
...
> (We haven't implemented the kind of optimization
> mentioned below,
> but we hope to do it in a future release.)
...
> James Hague <james.hague@REDACTED> writes:
> 
> > Does the compiler not take advantage of functions
> being internal to a
> > module?  For example, if a function always returns
> a tuple which is
> > immediately unpacked, then the tuple construction
> can be avoided and
> > the values returned in Erlang registers.  At least
> I recall reading
> > about this somewhere.
> > 
> > If this is the case, then you wouldn't be able to
> call internal
> > functions directly.

Note that you can handle this by a simple high-level
transformation. For example, assume <A,B> is an
unboxed tuple and f/1 is originally a function
returning a tuple {A,B}. Then rewrite it as follows:

f(X) -> <A,B> = f_internal(X), {A,B}.

internal_f(X) -> Unboxed_definition_of_F.

(So internal_f/1 returns <E1,E2> rather than {E1,E2})

Here's the trick: inside the module, all local calls
to f are then rewritten to call internal_f, while
outside the module all remote calls (including ::, if
available) go to the ordinary f. 

Local calls will then exploit unboxed tuples, while
remote calls still use the default call/return
convention.

I believe some compilers (GHC?) do this as a
consequence of other optimizations (inlining, etc).
For example, a call f(E) would be optimized more or
less like this:

{P1,P2} = f(E)   

==> (inline f/1)

{P1,P2} = (begin <A,B> = internal_f(E), {A,B} end)   

==> (simplify mildly)

<A,B> = internal_f(E), P1=A, P2=B

Voila, the useless tuple is gone.

Best,
Thomas



	
		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/