Optimize handling of local fun variables in v3_kernel

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Hi,

This branch removes the so-called "reverse etha-conversion" from v3_kernel and
replaces it by a proper call to the make_fun internal BIF without the need of a
redundant lambda function every time the local fun variable is referenced.

There may be some test suites related to this in lib/compiler/test/
but I couldn't
find one; feel free to point me to them if any.

    https://github.com/nox/otp/compare/rm-reverse-eta-conversion
    https://github.com/nox/otp/compare/rm-reverse-eta-conversion.patch

    git fetch https://github.com/nox/otp/ rm-reverse-eta-conversion

Regards,

--
Anthony Ramine

Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Hi,

I've added a commit to the branch (6eebc6c), it allows
the compiler to substitute local functions' names now that
v3_kernel doesn't create a lambda for every one of them it
encounters.

This optimizes a lot my implementation of EEP37.

Regards,

Le 10 nov. 2012 ? 16:35, Anthony Ramine a ?crit :

> Hi,
>
> This branch removes the so-called "reverse etha-conversion" from v3_kernel and
> replaces it by a proper call to the make_fun internal BIF without the need of a
> redundant lambda function every time the local fun variable is referenced.
>
> There may be some test suites related to this in lib/compiler/test/
> but I couldn't
> find one; feel free to point me to them if any.
>
>    https://github.com/nox/otp/compare/rm-reverse-eta-conversion
>    https://github.com/nox/otp/compare/rm-reverse-eta-conversion.patch
>
>    git fetch https://github.com/nox/otp/ rm-reverse-eta-conversion

--
Anthony Ramine


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Robert Virding-5
There seems to be an awful lot in this patch which has nothing to do with what the patch is about, most of it in fact. Is there a rebase missing or something here?

Robert

----- Original Message -----

> From: "Anthony Ramine" <n.oxyde>
> To: "erlang-patches" <erlang-patches>
> Sent: Thursday, 15 November, 2012 5:29:01 PM
> Subject: Re: [erlang-patches] Optimize handling of local fun variables in v3_kernel
>
> Hi,
>
> I've added a commit to the branch (6eebc6c), it allows
> the compiler to substitute local functions' names now that
> v3_kernel doesn't create a lambda for every one of them it
> encounters.
>
> This optimizes a lot my implementation of EEP37.
>
> Regards,
>
> Le 10 nov. 2012 ? 16:35, Anthony Ramine a ?crit :
>
> > Hi,
> >
> > This branch removes the so-called "reverse etha-conversion" from
> > v3_kernel and
> > replaces it by a proper call to the make_fun internal BIF without
> > the need of a
> > redundant lambda function every time the local fun variable is
> > referenced.
> >
> > There may be some test suites related to this in lib/compiler/test/
> > but I couldn't
> > find one; feel free to point me to them if any.
> >
> >    https://github.com/nox/otp/compare/rm-reverse-eta-conversion
> >    https://github.com/nox/otp/compare/rm-reverse-eta-conversion.patch
> >
> >    git fetch https://github.com/nox/otp/ rm-reverse-eta-conversion
>
> --
> Anthony Ramine
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches
> http://erlang.org/mailman/listinfo/erlang-patches
>

Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Hi Robert,

Sorry I couldn't send this patch earlier because I was behind a damn firewall that blocks outgoing SMTP.

As I have rebased my branch against master earlier,
the compare links should be:
   https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion
   https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion.patch

I've come to realize there is a bug in the second commit which I'll try to fix today: if a variable that is bound to a local name function is in a guard, the propagation of its value will make beam_validator errors out with {invalid_store,{yy,0}}.

You shouldn't bother looking at the second commit until I fix this.

Regards,

--
Anthony Ramine

Le 16 nov. 2012 ? 01:44, Robert Virding <robert.virding> a ?crit :

> There seems to be an awful lot in this patch which has nothing to do with what the patch is about, most of it in fact. Is there a rebase missing or something here?
>
> Robert

Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Err, forgot to include the mailing-list. Sorry.

You can now look at it there shouldn't be any bug.

--
Anthony Ramine

Le 16 nov. 2012 ? 18:23, Anthony Ramine a ?crit :

> The commit is amended and the bug is fixed, variables which values
> are local function names are substituted everywhere but in guards.
>
> --
> Anthony Ramine
>
> Le 16 nov. 2012 ? 10:24, Anthony Ramine a ?crit :
>
>> Hi Robert,
>>
>> Sorry I couldn't send this patch earlier because I was behind a damn firewall that blocks outgoing SMTP.
>>
>> As I have rebased my branch against master earlier,
>> the compare links should be:
>>  https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion
>>  https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion.patch
>>
>> I've come to realize there is a bug in the second commit which I'll try to fix today: if a variable that is bound to a local name function is in a guard, the propagation of its value will make beam_validator errors out with {invalid_store,{yy,0}}.
>>
>> You shouldn't bother looking at the second commit until I fix this.
>>
>> Le 16 nov. 2012 ? 01:44, Robert Virding <robert.virding> a ?crit :
>>
>>> There seems to be an awful lot in this patch which has nothing to do with what the patch is about, most of it in fact. Is there a rebase missing or something here?


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Henrik Nord-3
In reply to this post by Anthony Ramine-2
in master-pu
On 11/10/2012 04:35 PM, Anthony Ramine wrote:

> Hi,
>
> This branch removes the so-called "reverse etha-conversion" from v3_kernel and
> replaces it by a proper call to the make_fun internal BIF without the need of a
> redundant lambda function every time the local fun variable is referenced.
>
> There may be some test suites related to this in lib/compiler/test/
> but I couldn't
> find one; feel free to point me to them if any.
>
>      https://github.com/nox/otp/compare/rm-reverse-eta-conversion
>      https://github.com/nox/otp/compare/rm-reverse-eta-conversion.patch
>
>      git fetch https://github.com/nox/otp/ rm-reverse-eta-conversion
>
> Regards,
>

--
/Henrik Nord Erlang/OTP


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
I've removed the second commit of this branch because I'm not happy with it and because it makes the mnesia test suites fail. Enabling propagatation of local function names should be another patch on its own, let's not put that in this branch.

Please refetch.

--
Anthony Ramine

Le 30 nov. 2012 ? 10:29, Henrik Nord a ?crit :

> in master-pu
> On 11/10/2012 04:35 PM, Anthony Ramine wrote:
>> Hi,
>>
>> This branch removes the so-called "reverse etha-conversion" from v3_kernel and
>> replaces it by a proper call to the make_fun internal BIF without the need of a
>> redundant lambda function every time the local fun variable is referenced.
>>
>> There may be some test suites related to this in lib/compiler/test/
>> but I couldn't
>> find one; feel free to point me to them if any.
>>
>>     https://github.com/nox/otp/compare/rm-reverse-eta-conversion
>>     https://github.com/nox/otp/compare/rm-reverse-eta-conversion.patch
>>
>>     git fetch https://github.com/nox/otp/ rm-reverse-eta-conversion
>>
>> Regards,
>>
>
> --
> /Henrik Nord Erlang/OTP
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches
> http://erlang.org/mailman/listinfo/erlang-patches


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Fredrik
Hello Anthony,
Your patch is failing the following suites and tests;
trace_local_SUITE, exception_apply_function
trace_local_SUITE, exception_function
trace_local_SUITE, exception_meta_apply_function
trace_local_SUITE, exception_meta_function
trace_local_SUITE, exception_meta_nocatch_apply_function
trace_local_SUITE, exception_meta_nocatch_function
trace_local_SUITE, exception_nocatch_apply_function
trace_local_SUITE, exception_nocatch_function

Could you please fix this and then give me a notice,

BR Fredrik Gustafsson
Erlang OTP Team
On 12/03/2012 11:28 AM, Anthony Ramine wrote:
> I've removed the second commit of this branch because I'm not happy with it and because it makes the mnesia test suites fail. Enabling propagatation of local function names should be another patch on its own, let's not put that in this branch.
>
> Please refetch.
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Björn Gustavsson-2
The code looks fine.

I have only one comment for this part of the patch:

@@ -1663,6 +1655,19 @@ uexpr(#ifun{anno=A,vars=Vs,body=B0}, {break,Rs},
St0) ->
    #k_int{val=Index},#k_int{val=Uniq}|Fvs],
      ret=Rs},
      Free,add_local_function(Fun, St)};
+uexpr(#k_local{anno=A,name=Name,arity=Arity}, {break,Rs}, St) ->
+    Fs = get_free(Name, Arity, St),
+    FsCount = length(Fs),
+    Free = lit_list_vars(Fs),
+    %% Set dummy values for Index and Uniq -- the real values will
+    %% be assigned by beam_asm.
+    Index = Uniq = 0,
+    Bif = #k_bif{anno=#k{us=Free,ns=lit_list_vars(Rs),a=A},
+                 op=#k_internal{name=make_fun,arity=FsCount+3},
+                 args=[#k_atom{val=Name},#k_int{val=FsCount+Arity},
+                       #k_int{val=Index},#k_int{val=Uniq}|Fs],
+                 ret=Rs},
+    {Bif,Free,St};
 uexpr(Lit, {break,Rs0}, St0) ->
     %% Transform literals to puts here.
     %%ok = io:fwrite("uexpr ~w:~p~n", [?LINE,Lit]),

The code handles free variables. As far as I can understand, there
can be no free variables in this case, so you should simplify the code.



On Wed, Jan 9, 2013 at 4:51 PM, Fredrik <fredrik> wrote:

> Hello Anthony,
> Your patch is failing the following suites and tests;
> trace_local_SUITE, exception_apply_function
> trace_local_SUITE, exception_function
> trace_local_SUITE, exception_meta_apply_function
> trace_local_SUITE, exception_meta_function
> trace_local_SUITE, exception_meta_nocatch_apply_**function
> trace_local_SUITE, exception_meta_nocatch_**function
> trace_local_SUITE, exception_nocatch_apply_**function
> trace_local_SUITE, exception_nocatch_function
>
> Could you please fix this and then give me a notice,
>
> BR Fredrik Gustafsson
> Erlang OTP Team
>
> On 12/03/2012 11:28 AM, Anthony Ramine wrote:
>
>> I've removed the second commit of this branch because I'm not happy with
>> it and because it makes the mnesia test suites fail. Enabling propagatation
>> of local function names should be another patch on its own, let's not put
>> that in this branch.
>>
>> Please refetch.
>>
>>
> ______________________________**_________________
> erlang-patches mailing list
> erlang-patches
> http://erlang.org/mailman/**listinfo/erlang-patches<http://erlang.org/mailman/listinfo/erlang-patches>
>



--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130109/e408082e/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit :

> The code handles free variables. As far as I can understand, there
> can be no free variables in this case, so you should simplify the code.

You're right and wrong :) There can be no free variables if the Core Erlang
code comes from a current Erlang module, but there can be if the Core Erlang
was handwritten or generated by my EEP37 patch, for example:

module 'foo' ['bar'/1,
              'module_info'/0,
              'module_info'/1]
    attributes []
'bar'/1 =
    %% Line 4
    fun (_cor0) ->
        letrec
            'Bar'/1 =
                %% Line 5
                ( fun (_cor4) ->
                      let <Bar> = 'Bar'/1
                      in  case _cor4 of
                            <1> when 'true' ->
                                1
                            <N> when 'true' ->
                                let <_cor3> =
                                    call 'erlang':'*'
                                        (N, _cor0)
                                in  let <_cor1> =
                                        call 'erlang':'-'
                                            (N, 1)
                                    in  let <_cor2> =
                                            apply Bar
                                                (_cor1)
                                        in  call 'erlang':'*'
                                                (_cor3, _cor2)
                          end
                  -| [{'id',{0,0,'Bar'}}] )
        in  'Bar'/1
'module_info'/0 =
    fun () ->
        call 'erlang':'get_module_info'
            ('foo')
'module_info'/1 =
    fun (_cor0) ->
        call 'erlang':'get_module_info'
            ('foo', _cor0)
end

In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need
to be handled to remove the reverse eta conversion in a future-proof way.

The differences between master and my patch when running erlc +to_kernel foo.core
are:

--- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100
+++ foo.kernel 2013-01-10 13:27:36.000000000 +0100
@@ -5,18 +5,16 @@
 attributes []
 fdef 'bar'/1(_Xcor0) =
   do
-    bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0) >> <_ker2>
+    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0) >> <_ker1>
   then
-  <<_ker2>>
+  <<_ker1>>
 fdef 'module_info'/0() =
   enter (remote 'erlang':'get_module_info'/1)('foo')
 fdef 'module_info'/1(_Xcor0) =
   enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0)
-fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) =
-  enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0)
 fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) =
   do
-    bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0) >> <Bar>
+    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0) >> <Bar>
   then
   match _Xcor4
     alt
@@ -34,10 +32,8 @@
  call (Bar)(_Xcor1) >> <_Xcor2>
       then
       do
- bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2) >> <_ker1>
+ bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2) >> <_ker0>
       then
-      <<_ker1>>
+      <<_ker0>>
   end >> <>
-fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) =
-  enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0)
 end
\ No newline at end of file

Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you
when I'm done. Thanks for the feedback.

Regards,

--
Anthony Ramine


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Fredrik
In reply to this post by Fredrik
Thanks,
Re-fetched and I am building it now.

BR Fredrik Gustafsson
Erlang OTP Team
On 01/10/2013 04:42 PM, Anthony Ramine wrote:
> I've pushed a fix on the tip of the branch, please refetch.
>
> Regards,
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Fredrik
In reply to this post by Anthony Ramine-2
After further research we can see that the patch is also failing these
testcases in tools,
cover_SUITE, modules
cover_SUITE, on_load

Please fix this and give me notice,

BR Fredrik Gustafsson
Erlang OTP Team
On 01/10/2013 01:33 PM, Anthony Ramine wrote:

> Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit :
>
>> The code handles free variables. As far as I can understand, there
>> can be no free variables in this case, so you should simplify the code.
> You're right and wrong :) There can be no free variables if the Core Erlang
> code comes from a current Erlang module, but there can be if the Core Erlang
> was handwritten or generated by my EEP37 patch, for example:
>
> module 'foo' ['bar'/1,
>      'module_info'/0,
>      'module_info'/1]
>      attributes []
> 'bar'/1 =
>      %% Line 4
>      fun (_cor0) ->
> letrec
>    'Bar'/1 =
> %% Line 5
> ( fun (_cor4) ->
> let<Bar>  = 'Bar'/1
>      in  case _cor4 of
> <1>  when 'true' ->
> 1
> <N>  when 'true' ->
> let<_cor3>  =
>    call 'erlang':'*'
> (N, _cor0)
> in  let<_cor1>  =
> call 'erlang':'-'
>    (N, 1)
>    in  let<_cor2>  =
>    apply Bar
> (_cor1)
> in  call 'erlang':'*'
> (_cor3, _cor2)
>  end
>  -| [{'id',{0,0,'Bar'}}] )
> in  'Bar'/1
> 'module_info'/0 =
>      fun () ->
> call 'erlang':'get_module_info'
>    ('foo')
> 'module_info'/1 =
>      fun (_cor0) ->
> call 'erlang':'get_module_info'
>    ('foo', _cor0)
> end
>
> In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need
> to be handled to remove the reverse eta conversion in a future-proof way.
>
> The differences between master and my patch when running erlc +to_kernel foo.core
> are:
>
> --- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100
> +++ foo.kernel 2013-01-10 13:27:36.000000000 +0100
> @@ -5,18 +5,16 @@
>   attributes []
>   fdef 'bar'/1(_Xcor0) =
>     do
> -    bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0)>>  <_ker2>
> +    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>>  <_ker1>
>     then
> -<<_ker2>>
> +<<_ker1>>
>   fdef 'module_info'/0() =
>     enter (remote 'erlang':'get_module_info'/1)('foo')
>   fdef 'module_info'/1(_Xcor0) =
>     enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0)
> -fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) =
> -  enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0)
>   fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) =
>     do
> -    bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0)>>  <Bar>
> +    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>>  <Bar>
>     then
>     match _Xcor4
>       alt
> @@ -34,10 +32,8 @@
>   call (Bar)(_Xcor1)>>  <_Xcor2>
>         then
>         do
> - bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>>  <_ker1>
> + bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>>  <_ker0>
>         then
> -<<_ker1>>
> +<<_ker0>>
>     end>>  <>
> -fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) =
> -  enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0)
>   end
> \ No newline at end of file
>
> Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you
> when I'm done. Thanks for the feedback.
>
> Regards,
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Hi Fredrik,

I can't find any modules nor on_load cases in cover_SUITE.

Regards,

--
Anthony Ramine

Le 15 janv. 2013 ? 10:42, Fredrik a ?crit :

> After further research we can see that the patch is also failing these testcases in tools,
> cover_SUITE, modules
> cover_SUITE, on_load
>
> Please fix this and give me notice,
>
> BR Fredrik Gustafsson
> Erlang OTP Team
> On 01/10/2013 01:33 PM, Anthony Ramine wrote:
>> Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit :
>>
>>> The code handles free variables. As far as I can understand, there
>>> can be no free variables in this case, so you should simplify the code.
>> You're right and wrong :) There can be no free variables if the Core Erlang
>> code comes from a current Erlang module, but there can be if the Core Erlang
>> was handwritten or generated by my EEP37 patch, for example:
>>
>> module 'foo' ['bar'/1,
>>      'module_info'/0,
>>      'module_info'/1]
>>     attributes []
>> 'bar'/1 =
>>     %% Line 4
>>     fun (_cor0) ->
>> letrec
>>    'Bar'/1 =
>> %% Line 5
>> ( fun (_cor4) ->
>> let<Bar>  = 'Bar'/1
>>      in  case _cor4 of
>> <1>  when 'true' ->
>> 1
>> <N>  when 'true' ->
>> let<_cor3>  =
>>    call 'erlang':'*'
>> (N, _cor0)
>> in  let<_cor1>  =
>> call 'erlang':'-'
>>    (N, 1)
>>    in  let<_cor2>  =
>>    apply Bar
>> (_cor1)
>> in  call 'erlang':'*'
>> (_cor3, _cor2)
>>  end
>>  -| [{'id',{0,0,'Bar'}}] )
>> in  'Bar'/1
>> 'module_info'/0 =
>>     fun () ->
>> call 'erlang':'get_module_info'
>>    ('foo')
>> 'module_info'/1 =
>>     fun (_cor0) ->
>> call 'erlang':'get_module_info'
>>    ('foo', _cor0)
>> end
>>
>> In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need
>> to be handled to remove the reverse eta conversion in a future-proof way.
>>
>> The differences between master and my patch when running erlc +to_kernel foo.core
>> are:
>>
>> --- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100
>> +++ foo.kernel 2013-01-10 13:27:36.000000000 +0100
>> @@ -5,18 +5,16 @@
>>  attributes []
>>  fdef 'bar'/1(_Xcor0) =
>>    do
>> -    bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0)>>  <_ker2>
>> +    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>>  <_ker1>
>>    then
>> -<<_ker2>>
>> +<<_ker1>>
>>  fdef 'module_info'/0() =
>>    enter (remote 'erlang':'get_module_info'/1)('foo')
>>  fdef 'module_info'/1(_Xcor0) =
>>    enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0)
>> -fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) =
>> -  enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0)
>>  fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) =
>>    do
>> -    bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0)>>  <Bar>
>> +    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>>  <Bar>
>>    then
>>    match _Xcor4
>>      alt
>> @@ -34,10 +32,8 @@
>>   call (Bar)(_Xcor1)>>  <_Xcor2>
>>        then
>>        do
>> - bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>>  <_ker1>
>> + bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>>  <_ker0>
>>        then
>> -<<_ker1>>
>> +<<_ker0>>
>>    end>>  <>
>> -fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) =
>> -  enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0)
>>  end
>> \ No newline at end of file
>>
>> Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you
>> when I'm done. Thanks for the feedback.
>>
>> Regards,
>>
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Fredrik
My bad, cprof_SUITE for both

BR Fredrik Gustafsson
Erlang OTP Team
On 01/15/2013 11:39 AM, Anthony Ramine wrote:
> Hi Fredrik,
>
> I can't find any modules nor on_load cases in cover_SUITE.
>
> Regards,
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Fixed by not using fun references in the two test cases.

Please refetch.

--
Anthony Ramine

Le 15 janv. 2013 ? 11:41, Fredrik a ?crit :

> My bad, cprof_SUITE for both
>
> BR Fredrik Gustafsson
> Erlang OTP Team
> On 01/15/2013 11:39 AM, Anthony Ramine wrote:
>> Hi Fredrik,
>>
>> I can't find any modules nor on_load cases in cover_SUITE.
>>
>> Regards,
>>
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Fredrik
Re-fetched,
Thanks.

BR Fredrik Gustafsson
Erlang OTP Team
On 01/15/2013 01:17 PM, Anthony Ramine wrote:
> Fixed by not using fun references in the two test cases.
>
> Please refetch.
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Fredrik
In reply to this post by Anthony Ramine-2
Hello,
Graduated to master!
Thanks for your contribution!

BR Fredrik Gustafsson
Erlang OTP Team
On 01/15/2013 11:39 AM, Anthony Ramine wrote:

> Hi Fredrik,
>
> I can't find any modules nor on_load cases in cover_SUITE.
>
> Regards,
>
> -- Anthony Ramine Le 15 janv. 2013 ? 10:42, Fredrik a ?crit :
>> >  After further research we can see that the patch is also failing these testcases in tools,
>> >  cover_SUITE, modules
>> >  cover_SUITE, on_load
>> >  
>> >  Please fix this and give me notice,
>> >  
>> >  BR Fredrik Gustafsson
>> >  Erlang OTP Team
>> >  On 01/10/2013 01:33 PM, Anthony Ramine wrote:
>>> >>  Le 9 janv. 2013 ? 17:32, Bj?rn Gustavsson a ?crit :
>>> >>  
>>>> >>>  The code handles free variables. As far as I can understand, there
>>>> >>>  can be no free variables in this case, so you should simplify the code.
>>> >>  You're right and wrong:)  There can be no free variables if the Core Erlang
>>> >>  code comes from a current Erlang module, but there can be if the Core Erlang
>>> >>  was handwritten or generated by my EEP37 patch, for example:
>>> >>  
>>> >>  module 'foo' ['bar'/1,
>>> >>   'module_info'/0,
>>> >>   'module_info'/1]
>>> >>       attributes []
>>> >>  'bar'/1 =
>>> >>       %% Line 4
>>> >>       fun (_cor0) ->
>>> >>   letrec
>>> >>   'Bar'/1 =
>>> >>   %% Line 5
>>> >>   ( fun (_cor4) ->
>>> >>   let<Bar>   = 'Bar'/1
>>> >>   in  case _cor4 of
>>> >>   <1>   when 'true' ->
>>> >>   1
>>> >>   <N>   when 'true' ->
>>> >>   let<_cor3>   =
>>> >>   call 'erlang':'*'
>>> >>   (N, _cor0)
>>> >>   in  let<_cor1>   =
>>> >>   call 'erlang':'-'
>>> >>   (N, 1)
>>> >>   in  let<_cor2>   =
>>> >>   apply Bar
>>> >>   (_cor1)
>>> >>   in  call 'erlang':'*'
>>> >>   (_cor3, _cor2)
>>> >>   end
>>> >>   -| [{'id',{0,0,'Bar'}}] )
>>> >>   in  'Bar'/1
>>> >>  'module_info'/0 =
>>> >>       fun () ->
>>> >>   call 'erlang':'get_module_info'
>>> >>   ('foo')
>>> >>  'module_info'/1 =
>>> >>       fun (_cor0) ->
>>> >>   call 'erlang':'get_module_info'
>>> >>   ('foo', _cor0)
>>> >>  end
>>> >>  
>>> >>  In 'bar'/1, _cor0 is a free variable inside 'Bar'/1; thus free variables need
>>> >>  to be handled to remove the reverse eta conversion in a future-proof way.
>>> >>  
>>> >>  The differences between master and my patch when running erlc +to_kernel foo.core
>>> >>  are:
>>> >>  
>>> >>  --- foo.kernel.orig 2013-01-10 13:27:28.000000000 +0100
>>> >>  +++ foo.kernel 2013-01-10 13:27:36.000000000 +0100
>>> >>  @@ -5,18 +5,16 @@
>>> >>    attributes []
>>> >>    fdef 'bar'/1(_Xcor0) =
>>> >>      do
>>> >>  -    bif (internal 'make_fun'/4)('-bar/1-anonymous-2-', 2, 0, 0, _Xcor0)>>   <_ker2>
>>> >>  +    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>>   <_ker1>
>>> >>      then
>>> >>  -<<_ker2>>
>>> >>  +<<_ker1>>
>>> >>    fdef 'module_info'/0() =
>>> >>      enter (remote 'erlang':'get_module_info'/1)('foo')
>>> >>    fdef 'module_info'/1(_Xcor0) =
>>> >>      enter (remote 'erlang':'get_module_info'/2)('foo', _Xcor0)
>>> >>  -fdef '-bar/1-anonymous-2-'/2(_ker0, _Xcor0) =
>>> >>  -  enter (local '-bar/1-Bar/1-0-'/2)(_ker0, _Xcor0)
>>> >>    fdef '-bar/1-Bar/1-0-'/2(_Xcor4, _Xcor0) =
>>> >>      do
>>> >>  -    bif (internal 'make_fun'/4)('-bar/1-anonymous-1-', 2, 0, 0, _Xcor0)>>   <Bar>
>>> >>  +    bif (internal 'make_fun'/4)('-bar/1-Bar/1-0-', 2, 0, 0, _Xcor0)>>   <Bar>
>>> >>      then
>>> >>      match _Xcor4
>>> >>        alt
>>> >>  @@ -34,10 +32,8 @@
>>> >>     call (Bar)(_Xcor1)>>   <_Xcor2>
>>> >>          then
>>> >>          do
>>> >>  - bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>>   <_ker1>
>>> >>  + bif (remote 'erlang':'*'/2)(_Xcor3, _Xcor2)>>   <_ker0>
>>> >>          then
>>> >>  -<<_ker1>>
>>> >>  +<<_ker0>>
>>> >>      end>>   <>
>>> >>  -fdef '-bar/1-anonymous-1-'/2(V1, _Xcor0) =
>>> >>  -  enter (local '-bar/1-Bar/1-0-'/2)(V1, _Xcor0)
>>> >>    end
>>> >>  \ No newline at end of file
>>> >>  
>>> >>  Fredrik, I'll fix the failing test cases from trace_local_SUITE and come back to you
>>> >>  when I'm done. Thanks for the feedback.
>>> >>  
>>> >>  Regards,
>>> >>  


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
In reply to this post by Anthony Ramine-2
Hi,

I rebased my patch against latest maint. It should be safe to merge it now that
Kostis fixed the bug in HiPE.

Regards,

--
Anthony Ramine

Le 22 janv. 2013 ? 09:43, Fredrik a ?crit :

> Did you or Kostis find a solution to the problems with this patch and hipe?
>
> BR Fredrik Gustafsson
> Erlang OTP Team
> On 01/15/2013 01:17 PM, Anthony Ramine wrote:
>> Fixed by not using fun references in the two test cases.
>>
>> Please refetch.
>>
>


Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Kostis Sagonas-3
On 03/18/2013 03:13 PM, Anthony Ramine wrote:
> Hi,
>
> I rebased my patch against latest maint. It should be safe to merge it now that
> Kostis fixed the bug in HiPE.

For the record, in this particular case there was no bug in HiPE.

For better or worse, the HiPE compiler relies on certain invariants in
the code that the BEAM compiler generates.  Whenever these invariants
get broken, perhaps for very good reasons as in this case, the HiPE
compiler also needs to be adapted to not rely on them anymore.  It's a
quite natural process in software components that depend on each other
that would not classify as a bug.

Kostis

Wishing there was a magic way for software to be "future compatible"...

Reply | Threaded
Open this post in threaded view
|

Optimize handling of local fun variables in v3_kernel

Anthony Ramine-2
Of course, I sais bug because I was too lazy to be correct.

Do you know of any other unsaid invariants on which behaviour HiPE depends and that might be changed in the future? Wouldn't that be documentation-worthy?

Regards,

--
Anthony Ramine

Le 18 mars 2013 ? 23:04, Kostis Sagonas <kostis> a ?crit :

> On 03/18/2013 03:13 PM, Anthony Ramine wrote:
>> Hi,
>>
>> I rebased my patch against latest maint. It should be safe to merge it now that
>> Kostis fixed the bug in HiPE.
>
> For the record, in this particular case there was no bug in HiPE.
>
> For better or worse, the HiPE compiler relies on certain invariants in the code that the BEAM compiler generates.  Whenever these invariants get broken, perhaps for very good reasons as in this case, the HiPE compiler also needs to be adapted to not rely on them anymore.  It's a quite natural process in software components that depend on each other that would not classify as a bug.
>
> Kostis
>
> Wishing there was a magic way for software to be "future compatible"...

12