FEfenollp·Aug 21, 2017
So if you look into [1] you'll find .hrl sources (actually .erl) and their .S counterpart in the subfolders. From these you will see that functions `a` and `b` look more and more like each other. Note that `b` is the literal version of `a`.
How much speedup?
Potentially infinite, at the price of compile time.
In real world cases though I don't have any data yet. I want to be able to compile a whole project first and that fails for one last reason, described in the README. But I have faith :)
The patterns that can be superoptimized are few for now. [2] describes how some of lists.erl functions work so that they can be supercompiled.
The long-term idea is to have a local(/global if secured) cache of code so that inter-module calls can be optimized if the developer wants.
My real world case/motivation is supercompilation of code such as [3]
Read the rest
(goal is to turn `a` into `b` at the assembly level).
This pattern is extremely common in my employer's software [4] (which is probably the biggest open source Erlang project AFAIK).
A short example of a being super compiled into b:
a() -> hd([get()]).
b() -> get().
[1] https://github.com/fenollp/erlscp/tree/master/test/asm_data
[2] https://github.com/fenollp/erlscp/blob/master/src/erlang_sup...
[3] https://github.com/fenollp/erlscp/blob/master/test/asm_data/...
[4] https://github.com/2600hz/kazoo