[erlang-questions] Inlining Restrictions

[David Mercer]

Are there any restrictions on when it is legal to do function inlining (with either the –compile(inline) directive or the compiler option)?  Reason I ask is that I have code that compiles fine without inlining but crashes with an “internal error in kernel_module” error when I enable inlining.  Am wondering if I could refactor my code and take out the offending statement and so allow function inlining.  Please advise.  Thank-you.

 

David

 

 

[Richard Carlsson]

If possible, please send me your code (or even better, a minimal
example that displays this bug) so I can have a look. Inlining is
supposed to work without any need for tweaking.

/Richard
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions

[David Mercer]

Having stripped the whole thing down to a minimal example, the problem
appears to be with using functions in guards. Here's my minimal example:

----------------------------------------------------------------------
-module(inline_test).
-compile(inline).
-export([exported_fun/0]).

exported_fun() -> fun_with_guard(fun used_in_guard/0).

fun_with_guard(GuardedFun) when is_function(GuardedFun) -> x.

used_in_guard() -> x.
----------------------------------------------------------------------

> -----Original Message-----
> From: Richard Carlsson [mailto:rich...@it.uu.se]
> Sent: Friday, November 21, 2008 12:20
> To: dme...@alum.mit.edu
> Cc: 'Erlang Questions'
> Subject: Re: [erlang-questions] Inlining Restrictions
>
> David Mercer wrote:
> > Are there any restrictions on when it is legal to do function inlining

> > (with either the -compile(inline) directive or the compiler option)?

[Richard Carlsson]

David Mercer wrote:
> Having stripped the whole thing down to a minimal example, the problem
> appears to be with using functions in guards. Here's my minimal example:
>
> ----------------------------------------------------------------------
> -module(inline_test).
> -compile(inline).
> -export([exported_fun/0]).
>
> exported_fun() -> fun_with_guard(fun used_in_guard/0).
>
> fun_with_guard(GuardedFun) when is_function(GuardedFun) -> x.
>
> used_in_guard() -> x.
> ----------------------------------------------------------------------

Thank you for doing that. The bad news is that it's a known bug
(to me), and I haven't had time to work on it. The good news is
that at least it's not a new bug. The problem is really that the
beam backend cannot handle fun-literals within guards, and the
inliner can sneak such a literal past the "lint" stage which checks
that the guards are valid, hence the crash. Of course, the limitation
is mainly an artificial one and should be fixed. (And I'll have to
find out why the inliner doesn't reduce the guard test to 'true'.)
I'll have to raise the priority on this one, but meanwhile you need to
find a way around it, perhaps by turning off inlining on this module.