Discussion:
[erlang-patches] Optimize handling of local fun variables in v3_kernel
unknown
2012-11-10 15:35:40 UTC
Permalink
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
unknown
2012-11-15 16:29:01 UTC
Permalink
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
unknown
2012-11-16 00:44:23 UTC
Permalink
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
>
unknown
2012-11-16 09:24:54 UTC
Permalink
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
unknown
2012-11-16 17:26:36 UTC
Permalink
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?
unknown
2012-11-30 09:29:13 UTC
Permalink
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
unknown
2012-12-03 10:28:57 UTC
Permalink
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
unknown
2013-01-09 15:51:42 UTC
Permalink
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.
>
unknown
2013-01-09 16:32:53 UTC
Permalink
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>
unknown
2013-01-10 12:33:03 UTC
Permalink
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
unknown
2013-01-15 09:42:24 UTC
Permalink
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,
>
unknown
2013-01-15 10:39:38 UTC
Permalink
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,
>>
>
unknown
2013-01-15 10:41:31 UTC
Permalink
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,
>
unknown
2013-01-15 12:17:35 UTC
Permalink
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,
>>
>
unknown
2013-01-15 13:13:19 UTC
Permalink
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.
>
unknown
2013-03-18 13:13:09 UTC
Permalink
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.
>>
>
unknown
2013-03-18 22:04:13 UTC
Permalink
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"...
unknown
2013-03-19 08:22:36 UTC
Permalink
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"...
unknown
2013-04-04 13:56:57 UTC
Permalink
On Mon, Mar 18, 2013 at 2:13 PM, Anthony Ramine <n.oxyde> wrote:

> Hi,
>
> I rebased my patch against latest maint. It should be safe to merge it now
> that
> Kostis fixed the bug in HiPE.
>
>
I have learned from my own experience that compiler optimizations
are always much easier to get wrong than one would think.

Therefore, we no longer include new compiler optimizations
in minor releases.

So, unfortunately, we can only include your patch in R17.

/Bjorn

--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130404/084c1061/attachment.html>
unknown
2013-04-04 14:03:30 UTC
Permalink
Will it be merged into master now or will I need to yet again submit it when R17 is around?

--
Anthony Ramine

Le 4 avr. 2013 ? 15:56, Bj?rn Gustavsson a ?crit :

> On Mon, Mar 18, 2013 at 2:13 PM, Anthony Ramine <n.oxyde> wrote:
> Hi,
>
> I rebased my patch against latest maint. It should be safe to merge it now that
> Kostis fixed the bug in HiPE.
>
>
> I have learned from my own experience that compiler optimizations
> are always much easier to get wrong than one would think.
>
> Therefore, we no longer include new compiler optimizations
> in minor releases.
>
> So, unfortunately, we can only include your patch in R17.
>
> /Bjorn
>
> --
> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130404/21b18a32/attachment.html>
unknown
2013-05-17 07:56:46 UTC
Permalink
On 04/04/2013 04:03 PM, Anthony Ramine wrote:
> Will it be merged into master now or will I need to yet again submit
> it when R17 is around?
>
> --
> Anthony Ramine
>
> Le 4 avr. 2013 ? 15:56, Bj?rn Gustavsson a ?crit :
>
>> On Mon, Mar 18, 2013 at 2:13 PM, Anthony Ramine <n.oxyde
>> <mailto:n.oxyde>> wrote:
>>
>> Hi,
>>
>> I rebased my patch against latest maint. It should be safe to
>> merge it now that
>> Kostis fixed the bug in HiPE.
>>
>>
>> I have learned from my own experience that compiler optimizations
>> are always much easier to get wrong than one would think.
>>
>> Therefore, we no longer include new compiler optimizations
>> in minor releases.
>>
>> So, unfortunately, we can only include your patch in R17.
>>
>> /Bjorn
>>
>> --
>> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
>
Hey Anthony,
I'm struggling with testing this patch, it still breaks with hipe_libs:

03999: erlc -W -Werror -o gen compiler/diameter_dict_parser.yrl
04000: erlc -W +debug_info +'{parse_transform,sys_pre_attributes}' +'{attribute,insert,app_vsn,"diameter-1.4.1.1"}' +warn_export_vars +warn_unused_vars -pa /lib/diameter/ebin -I ../include -I gen -o../ebin gen/diameter_dict_parser.erl
04001: \



--

BR Fredrik Gustafsson
Erlang OTP Team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130517/3cbe9ed4/attachment.html>
unknown
2013-05-17 08:28:07 UTC
Permalink
Will look into it. Thank you for the unexpected feedback :)

--
Anthony Ramine

Le 17 mai 2013 ? 09:56, Fredrik a ?crit :

> On 04/04/2013 04:03 PM, Anthony Ramine wrote:
>> Will it be merged into master now or will I need to yet again submit it when R17 is around?
>>
>> --
>> Anthony Ramine
>>
>> Le 4 avr. 2013 ? 15:56, Bj?rn Gustavsson a ?crit :
>>
>>> On Mon, Mar 18, 2013 at 2:13 PM, Anthony Ramine <n.oxyde> wrote:
>>> Hi,
>>>
>>> I rebased my patch against latest maint. It should be safe to merge it now that
>>> Kostis fixed the bug in HiPE.
>>>
>>>
>>> I have learned from my own experience that compiler optimizations
>>> are always much easier to get wrong than one would think.
>>>
>>> Therefore, we no longer include new compiler optimizations
>>> in minor releases.
>>>
>>> So, unfortunately, we can only include your patch in R17.
>>>
>>> /Bjorn
>>>
>>> --
>>> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
>>
> Hey Anthony,
> I'm struggling with testing this patch, it still breaks with hipe_libs:
> 03999: erlc -W -Werror -o gen compiler/diameter_dict_parser.yrl
> 04000: erlc -W +debug_info +'{parse_transform,sys_pre_attributes}' +'{attribute,insert,app_vsn,"diameter-1.4.1.1"}' +warn_export_vars +warn_unused_vars -pa /lib/diameter/ebin -I ../include -I gen -o../ebin gen/diameter_dict_parser.erl
> 04001: \
>
>
>
> --
>
> BR Fredrik Gustafsson
> Erlang OTP Team
>
unknown
2013-05-17 16:50:57 UTC
Permalink
I can't reproduce any crash with diameter_dict_parse, could you give me more details about it?

--
Anthony Ramine

Le 17 mai 2013 ? 10:28, Anthony Ramine a ?crit :

> Will look into it. Thank you for the unexpected feedback :)
>
> --
> Anthony Ramine
>
> Le 17 mai 2013 ? 09:56, Fredrik a ?crit :
>
>> On 04/04/2013 04:03 PM, Anthony Ramine wrote:
>>> Will it be merged into master now or will I need to yet again submit it when R17 is around?
>>>
>>> --
>>> Anthony Ramine
>>>
>>> Le 4 avr. 2013 ? 15:56, Bj?rn Gustavsson a ?crit :
>>>
>>>> On Mon, Mar 18, 2013 at 2:13 PM, Anthony Ramine <n.oxyde> wrote:
>>>> Hi,
>>>>
>>>> I rebased my patch against latest maint. It should be safe to merge it now that
>>>> Kostis fixed the bug in HiPE.
>>>>
>>>>
>>>> I have learned from my own experience that compiler optimizations
>>>> are always much easier to get wrong than one would think.
>>>>
>>>> Therefore, we no longer include new compiler optimizations
>>>> in minor releases.
>>>>
>>>> So, unfortunately, we can only include your patch in R17.
>>>>
>>>> /Bjorn
>>>>
>>>> --
>>>> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
>>>
>> Hey Anthony,
>> I'm struggling with testing this patch, it still breaks with hipe_libs:
>> 03999: erlc -W -Werror -o gen compiler/diameter_dict_parser.yrl
>> 04000: erlc -W +debug_info +'{parse_transform,sys_pre_attributes}' +'{attribute,insert,app_vsn,"diameter-1.4.1.1"}' +warn_export_vars +warn_unused_vars -pa /lib/diameter/ebin -I ../include -I gen -o../ebin gen/diameter_dict_parser.erl
>> 04001: \
>>
>>
>>
>> --
>>
>> BR Fredrik Gustafsson
>> Erlang OTP Team
>>
>
unknown
2013-05-20 07:33:14 UTC
Permalink
On 05/17/2013 06:50 PM, Anthony Ramine wrote:
> I can't reproduce any crash with diameter_dict_parse, could you give me more details about it?
>
Hello Anthony,
./configure flags are:
--enable-hipe --enable-smp-support --enable-native-libs
Did you try with those?

--

BR Fredrik Gustafsson
Erlang OTP Team
unknown
2013-05-20 11:35:26 UTC
Permalink
Just native-libs. Will try those now.

--
Anthony Ramine

Le 20 mai 2013 ? 09:33, Fredrik a ?crit :

> On 05/17/2013 06:50 PM, Anthony Ramine wrote:
>> I can't reproduce any crash with diameter_dict_parse, could you give me more details about it?
>>
> Hello Anthony,
> ./configure flags are:
> --enable-hipe --enable-smp-support --enable-native-libs
> Did you try with those?
>
> --
>
> BR Fredrik Gustafsson
> Erlang OTP Team
>
unknown
2013-05-20 15:05:02 UTC
Permalink
Still no problem. What was the actual error or crash?

--
Anthony Ramine

Le 20 mai 2013 ? 13:35, Anthony Ramine a ?crit :

> Just native-libs. Will try those now.
>
> --
> Anthony Ramine
>
> Le 20 mai 2013 ? 09:33, Fredrik a ?crit :
>
>> On 05/17/2013 06:50 PM, Anthony Ramine wrote:
>>> I can't reproduce any crash with diameter_dict_parse, could you give me more details about it?
>>>
>> Hello Anthony,
>> ./configure flags are:
>> --enable-hipe --enable-smp-support --enable-native-libs
>> Did you try with those?
>>
>> --
>>
>> BR Fredrik Gustafsson
>> Erlang OTP Team
>>
>
unknown
2013-09-05 15:40:05 UTC
Permalink
What happened to that patch?

Le 20 mai 2013 ? 17:05, Anthony Ramine a ?crit :

> Still no problem. What was the actual error or crash?
>
> --
> Anthony Ramine
>
> Le 20 mai 2013 ? 13:35, Anthony Ramine a ?crit :
>
>> Just native-libs. Will try those now.
>>
>> --
>> Anthony Ramine
>>
>> Le 20 mai 2013 ? 09:33, Fredrik a ?crit :
>>
>>> On 05/17/2013 06:50 PM, Anthony Ramine wrote:
>>>> I can't reproduce any crash with diameter_dict_parse, could you give me more details about it?
>>>>
>>> Hello Anthony,
>>> ./configure flags are:
>>> --enable-hipe --enable-smp-support --enable-native-libs
>>> Did you try with those?
>>>
>>> --
>>>
>>> BR Fredrik Gustafsson
>>> Erlang OTP Team
>>>
>>
>
unknown
2013-09-15 12:12:31 UTC
Permalink
Ping?

This patch will be important in the context of named funs to reduce user surprise with some convoluted snippets of code, e.g.:

F = fun Self() -> Self end, true = F =:= F().
F = fun IsMe(G) when IsMe =:= G -> ok end, F(F).

Regards,

Le 5 sept. 2013 ? 17:40, Anthony Ramine a ?crit :

> What happened to that patch?
>
> Le 20 mai 2013 ? 17:05, Anthony Ramine a ?crit :
>
>> Still no problem. What was the actual error or crash?
>>
>> --
>> Anthony Ramine
>>
>> Le 20 mai 2013 ? 13:35, Anthony Ramine a ?crit :
>>
>>> Just native-libs. Will try those now.
>>>
>>> --
>>> Anthony Ramine
>>>
>>> Le 20 mai 2013 ? 09:33, Fredrik a ?crit :
>>>
>>>> On 05/17/2013 06:50 PM, Anthony Ramine wrote:
>>>>> I can't reproduce any crash with diameter_dict_parse, could you give me more details about it?
>>>>>
>>>> Hello Anthony,
>>>> ./configure flags are:
>>>> --enable-hipe --enable-smp-support --enable-native-libs
>>>> Did you try with those?
>>>>
>>>> --
>>>>
>>>> BR Fredrik Gustafsson
>>>> Erlang OTP Team
>>>>
>>>
>>
>
unknown
2013-09-16 09:08:54 UTC
Permalink
On 09/15/2013 02:12 PM, Anthony Ramine wrote:
> Ping?
>
> This patch will be important in the context of named funs to reduce user surprise with some convoluted snippets of code, e.g.:
>
> F = fun Self() -> Self end, true = F =:= F().
> F = fun IsMe(G) when IsMe =:= G -> ok end, F(F).
>
> Regards,
>
> Le 5 sept. 2013 ? 17:40, Anthony Ramine a ?crit :
>
>> What happened to that patch?
>>
>> Le 20 mai 2013 ? 17:05, Anthony Ramine a ?crit :
>>
>>> Still no problem. What was the actual error or crash?
>>>
>>> --
>>> Anthony Ramine
>>>
>>> Le 20 mai 2013 ? 13:35, Anthony Ramine a ?crit :
>>>
>>>> Just native-libs. Will try those now.
>>>>
>>>> --
>>>> Anthony Ramine
>>>>
>>>> Le 20 mai 2013 ? 09:33, Fredrik a ?crit :
>>>>
>>>>> On 05/17/2013 06:50 PM, Anthony Ramine wrote:
>>>>>> I can't reproduce any crash with diameter_dict_parse, could you give me more details about it?
>>>>>>
>>>>> Hello Anthony,
>>>>> ./configure flags are:
>>>>> --enable-hipe --enable-smp-support --enable-native-libs
>>>>> Did you try with those?
>>>>>
>>>>> --
>>>>>
>>>>> BR Fredrik Gustafsson
>>>>> Erlang OTP Team
>>>>>
Hello Anthony,
Afaik the same issue is remaining as we discussed in private
conversation i.e
with these flags the build aborts:
CONFIG_FLAGS = --enable-hipe --enable-smp-support --enable-native-libs

--

BR Fredrik Gustafsson
Erlang OTP Team
unknown
2013-09-16 09:37:56 UTC
Permalink
I can't reproduce the issue, you were supposed to give me a core dump or something by "tomorrow", that was May 27th :)

Le 16 sept. 2013 ? 11:08, Fredrik a ?crit :

> Hello Anthony,
> Afaik the same issue is remaining as we discussed in private conversation i.e
> with these flags the build aborts:
> CONFIG_FLAGS = --enable-hipe --enable-smp-support --enable-native-libs
unknown
2013-09-19 13:18:12 UTC
Permalink
Received the core dump.

In this GDB session (https://gist.github.com/nox/6623009) you can notice at the end that HiPE tries to patch a LOT of fun entries for the same erl_prettypr:lay/2 function. This is because I forgot to strip the eta-abstracted id annotations when compiling local fun references to Core Erlang in v3_core. I amended the first commit of that branch to fix that.

Please refetch.

Regards,

Le 16 sept. 2013 ? 11:37, Anthony Ramine a ?crit :

> I can't reproduce the issue, you were supposed to give me a core dump or something by "tomorrow", that was May 27th :)
>
> Le 16 sept. 2013 ? 11:08, Fredrik a ?crit :
>
>> Hello Anthony,
>> Afaik the same issue is remaining as we discussed in private conversation i.e
>> with these flags the build aborts:
>> CONFIG_FLAGS = --enable-hipe --enable-smp-support --enable-native-libs
>
unknown
2013-10-08 16:57:19 UTC
Permalink
Hello Kostis,

Any idea why this still segfaults if HiPE is enabled?

Regards,

Le 19 sept. 2013 ? 15:18, Anthony Ramine a ?crit :

> Received the core dump.
>
> In this GDB session (https://gist.github.com/nox/6623009) you can notice at the end that HiPE tries to patch a LOT of fun entries for the same erl_prettypr:lay/2 function. This is because I forgot to strip the eta-abstracted id annotations when compiling local fun references to Core Erlang in v3_core. I amended the first commit of that branch to fix that.
>
> Please refetch.
>
> Regards,
>
> Le 16 sept. 2013 ? 11:37, Anthony Ramine a ?crit :
>
>> I can't reproduce the issue, you were supposed to give me a core dump or something by "tomorrow", that was May 27th :)
>>
>> Le 16 sept. 2013 ? 11:08, Fredrik a ?crit :
>>
>>> Hello Anthony,
>>> Afaik the same issue is remaining as we discussed in private conversation i.e
>>> with these flags the build aborts:
>>> CONFIG_FLAGS = --enable-hipe --enable-smp-support --enable-native-libs
>>
>

--
Anthony Ramine
unknown
2013-10-14 10:45:38 UTC
Permalink
Hello Kostis,

To reproduce the crash, compile the following module with +native with my rm-reverse-eta-conversion branch:

-module(t).
-export([t1/0,t2/0]).

t1() -> fun identity/1.
t2() -> fun identity/2.

identity(X) -> X.

Loading this module compiled with HiPE on my branch will make HiPE crash in patch_funentries. Commenting the t2/0 function out makes the crash disappear. That shows that the cause of the crash is multiple references to the same local function.

Regards,

--
Anthony Ramine

Le 8 oct. 2013 ? 20:12, Kostis Sagonas <kostis> a ?crit :

> Anyway, I am not sure how to contribute here and it will take me quite some time to investigate this from scratch, time which sadly I do not have these days. I can spend some time on this if I feel like hacking again one of the nights to come, but only if you minimize this and send me a self-contained module that shows the problem when you generate BEAM code with the changed compiler, but not with the vanilla.
unknown
2013-10-14 11:07:26 UTC
Permalink
Err,

t2() -> fun identity/1.

--
Anthony Ramine

> Le 14 oct. 2013 ? 12:45, Anthony Ramine <n.oxyde> a ?crit :
>
> Hello Kostis,
>
> To reproduce the crash, compile the following module with +native with my rm-reverse-eta-conversion branch:
>
> -module(t).
> -export([t1/0,t2/0]).
>
> t1() -> fun identity/1.
> t2() -> fun identity/2.
>
> identity(X) -> X.
>
> Loading this module compiled with HiPE on my branch will make HiPE crash in patch_funentries. Commenting the t2/0 function out makes the crash disappear. That shows that the cause of the crash is multiple references to the same local function.
>
> Regards,
>
> --
> Anthony Ramine
>
>> Le 8 oct. 2013 ? 20:12, Kostis Sagonas <kostis> a ?crit :
>>
>> Anyway, I am not sure how to contribute here and it will take me quite some time to investigate this from scratch, time which sadly I do not have these days. I can spend some time on this if I feel like hacking again one of the nights to come, but only if you minimize this and send me a self-contained module that shows the problem when you generate BEAM code with the changed compiler, but not with the vanilla.
>
unknown
2014-01-26 15:10:38 UTC
Permalink
Kostis, ping?

--
Anthony Ramine

Le 14 oct. 2013 ? 13:07, Anthony Ramine <n.oxyde> a ?crit :

> Err,
>
> t2() -> fun identity/1.
>
> --
> Anthony Ramine
>
>> Le 14 oct. 2013 ? 12:45, Anthony Ramine <n.oxyde> a ?crit :
>>
>> Hello Kostis,
>>
>> To reproduce the crash, compile the following module with +native with my rm-reverse-eta-conversion branch:
>>
>> -module(t).
>> -export([t1/0,t2/0]).
>>
>> t1() -> fun identity/1.
>> t2() -> fun identity/2.
>>
>> identity(X) -> X.
>>
>> Loading this module compiled with HiPE on my branch will make HiPE crash in patch_funentries. Commenting the t2/0 function out makes the crash disappear. That shows that the cause of the crash is multiple references to the same local function.
>>
>> Regards,
>>
>> --
>> Anthony Ramine
>>
>>> Le 8 oct. 2013 ? 20:12, Kostis Sagonas <kostis> a ?crit :
>>>
>>> Anyway, I am not sure how to contribute here and it will take me quite some time to investigate this from scratch, time which sadly I do not have these days. I can spend some time on this if I feel like hacking again one of the nights to come, but only if you minimize this and send me a self-contained module that shows the problem when you generate BEAM code with the changed compiler, but not with the vanilla.
>>
unknown
2013-01-18 09:41:03 UTC
Permalink
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,
>>> >>
unknown
2013-01-10 15:49:24 UTC
Permalink
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,
>
Henrik Nord
2015-02-12 09:27:55 UTC
Permalink
Hello Anthony!

Whats the status of this patch?
nox/rm-reverse-eta-conversion
https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion

Open a PR if it is still relevant, Im closing this specific patch thread.

--
/Henrik Nord Erlang/OTP
Anthony Ramine
2015-02-12 10:35:30 UTC
Permalink
Hello Henrik,

Kostis was supposed to come back to me to talk about this patch but I'm still waiting, you can close that thread.

Le 12 févr. 2015 à 10:27, Henrik Nord <***@erlang.org> a écrit :

> Hello Anthony!
>
> Whats the status of this patch?
> nox/rm-reverse-eta-conversion
> https://github.com/nox/otp/compare/erlang:master...rm-reverse-eta-conversion
>
> Open a PR if it is still relevant, Im closing this specific patch thread.
>
> --
> /Henrik Nord Erlang/OTP
>
Loading...