Optimize handling of local fun variables in v3_kernel
Locked
12
12
Optimize handling of local fun variables in v3_kernel
 
|
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 |
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 |
Optimize handling of local fun variables in v3_kernel
|
|
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 > |
Optimize handling of local fun variables in v3_kernel
|
|
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 |
Optimize handling of local fun variables in v3_kernel
|
|
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? |
Optimize handling of local fun variables in v3_kernel
|
|
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 |
Optimize handling of local fun variables in v3_kernel
|
|
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 |
|
|
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. > |
Optimize handling of local fun variables in v3_kernel
|
|
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> |
Optimize handling of local fun variables in v3_kernel
|
|
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 |
|
|
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, > |
|
|
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, > |
Optimize handling of local fun variables in v3_kernel
|
|
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, > |
Optimize handling of local fun variables in v3_kernel
|
|
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. > |
|
|
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, >>> >> |
Optimize handling of local fun variables in v3_kernel
|
|
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. >> > |
Optimize handling of local fun variables in v3_kernel
|
|
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"... |
Optimize handling of local fun variables in v3_kernel
|
|
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"... |
«
Return to Erlang Patches
|
1 view|%1 views
| Free forum by Nabble | Edit this page |