|
|
12
|
|
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 :
--
Anthony Ramine
|
|
|
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>
|
|
|
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.patchI'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
|
|
|
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?
|
|
|
in master-pu
On 11/10/2012 04:35 PM, Anthony Ramine wrote:
--
/Henrik Nord Erlang/OTP
|
|
|
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 :
|
|
|
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.
>
|
|
|
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>
|
|
|
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
|
|
|
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,
>
|
|
|
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,
>
|
|
|
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,
>>
>
|
|
|
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,
>
|
|
|
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,
>>
>
|
|
|
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.
>
|
|
|
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,
>>> >>
|
|
|
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.
>>
>
|
|
|
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"...
|
|
|
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
|
Locked
