[erlang-bugs] inline & inline_effort

[Tony Rogvall]

THAT WAS NOT FUNNY :-)

I do not see what low level transformation has to do with anything in 
the example I sent. It is just a plain module that illustrate some problem
with an undocumented feature that I found looking through the code.
(Upping the default inline_effort from 24 to say 100 might have exposed it anyway)

In the inline transform that I am writing I read forms from the beam files compiled with debug_info
and then toss them into the module, cleaning and massaging a bit. It is not on core Erlang level at all.
And does not have to be. The rest is passed on to the regular compiler to work on.

Regards

/Tony


On 9 sep 2013, at 10:54, Anthony Ramine <n.oxyde@REDACTED> wrote:

> Hey don't remove Core transforms, I use them :p
> 
> https://github.com/nox/shippai
> 
> -- 
> Anthony Ramine
> 
> Le 9 sept. 2013 à 10:42, Björn-Egil Dahlberg <egil@REDACTED> a écrit :
> 
>> On 2013-09-09 08:56, Anthony Ramine wrote:
>>> Hi Tony,
>>> 
>>> Btw for low-level transformations, you should rather make a Core Erlang transform, it is way easier to reason about.
>> +1, do it in core erlang
>> 
>> or wait that's a novel idea, perhaps we should remove it .. =)
>> 
>> // Björn-Egil
>> 
>> 
>>> 
>>> Regards,
>>> 
>>> Le 8 sept. 2013 à 22:55, Tony Rogvall a écrit :
>>> 
>>>> Hi!
>>>> 
>>>> I dont know who is working on the cerl_inline functionality but it is really intriguing !
>>>> I have found some problems doing experiments with (undocumented) compile attributes
>>>> inline_effort and inline_unroll. No No No do not remove them!!!! They just needs to be
>>>> tested and reworked a bit :-)
>>>> 
>>>> I am working on a module inline parse transform that I need for speed things up a bit,
>>>> specially on modules that I think will not change so much over time (think lists module)
>>>> Also, hipe compile on top of this tends to do marvelous things with performance :-)
>>>> 
>>>> Any way here is a module that when compiled, first of all warns about some strange things
>>>> and then generates some "interesting" code.
>>>> 
>>>> I guess the ones working on this will see what is the problem. And please do NOT remove
>>>> functionality just because I found it, improve it. I need it :-)
>>>> 
>>>> Thanks
>>>> 
>>>> 
>>>> /Tony
>>>> 
>>>> 
>>>> 
>>>> -module(example3i).
>>>> 
>>>> -export([run/1]).
>>>> 
>>>> -compile(inline).
>>>> -compile({inline_size,   500}).    %% default=24
>>>> -compile({inline_effort, 500}).   %% default=150
>>>> %% -compile({inline_unroll, 1}).   %% default=1
>>>> -compile({verbose,true}).
>>>> 
>>>> run(V) when is_float(V) ->
>>>>   B = vec3f_new(4,5,6),
>>>>   C = vec3f_new(7,8,9),
>>>>   vec3f_multiply(V,vec3f_add(B,C)).
>>>> 
>>>> -define(is_vecA, is_float(A1), is_float(A2), is_float(A3)).
>>>> -define(is_vecB, is_float(B1), is_float(B2), is_float(B3)).
>>>> 
>>>> vec3f_new(X,Y,Z) when is_number(X), is_number(Y), is_number(Z) ->
>>>>   {float(X),float(Y),float(Z)}.
>>>> 
>>>> vec3f_add({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB ->
>>>>   {A1+B1,A2+B2,A3+B3}.
>>>> 
>>>> vec3f_multiply({A1,A2,A3},{B1,B2,B3}) when ?is_vecA, ?is_vecB ->
>>>>   {A1*B1,A2*B2,A3*B3};
>>>> vec3f_multiply(A, {B1,B2,B3}) when is_float(A), ?is_vecB ->
>>>>   {A*B1,A*B2,A*B3};
>>>> vec3f_multiply({A1,A2,A3}, B) when is_float(B), ?is_vecA ->
>>>>   {A1*B,A2*B,A3*B}.
>>>> 
>>>> 
>>>> _______________________________________________
>>>> erlang-bugs mailing list
>>>> erlang-bugs@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>> _______________________________________________
>>> erlang-bugs mailing list
>>> erlang-bugs@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-bugs
>> 
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130909/e8aa0416/attachment.htm>