[erlang-bugs] Enhancement to compiler-4.5.4 documentation

Edwin Fine <>
Sun Oct 5 10:49:34 CEST 2008

On Sun, Oct 5, 2008 at 2:18 AM, Bjorn Gustavsson <>wrote:

> 2008/10/4 Edwin Fine <>
>> In the documentation for compiler-4.5.4, in the options it states
>> export_all Causes all functions in the module to be exported.This does
>> not explain that previously inlined functions become "uninlined" and are
>> also exported. I suggest changing this to the following:
> Are you sure about "uninlined"?

It was a bad explanation on my part to write "uninlined." What I meant there
is that a separate, standalone function is also created.  Before I wrote
this email I had already looked at the assembler to check my facts and had
seen that the function was still inlined, but also created as a separate
function. Bad wording, sorry.

> The expected behavior is that exported functions are still inlined, but
> still kept as a exported functions. Examining
> the assembly code for the following module
> -module(t).
> -compile(export_all).
> -export([t/0]).
> -compile({inline,[{foo,0}]}).
> t() ->
>     foo().
> foo() ->
>     42.
> it can be seen that the call to foo/0 has been replaced with 42 in t/0.

Yes, agreed.

>  export_all Causes all functions in the module to be exported*, including
>> functions that are declared as inline.*I think it's rather important to
>> know this.
> Why? The functions are still being inlined as expected.

My concern is that the extra separate function bodies take up unnecessary
space, and if there are many functions included in many modules (as there
are in my situation, where I have 5 inlined functions in an hrl file that
gets included everywhere), it could create significant code bloat (say, 50
modules and 4 unused but exported functions per module). Granted, this is
only likely to happen if export_all is applied in the compilation of all
modules. And granted, the expansion of the inlined code is likely to cause
much more bloat than the extra unused functions.

If you tell me this is not an issue, I will accept that. In any case, it
wouldn't hurt to put this is the documentation, would it?


Edwin Fin e

> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20081005/5eb2463a/attachment.html>

More information about the erlang-bugs mailing list