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`

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] (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 https://github.com/fenollp/erlscp/tree/master/test/asm_data [2] https://github.com/fenollp/erlscp/blob/master/src/erlang_supercompiler.erl#L29 https://github.com/fenollp/erlscp/blob/master/src/erlang_sup... [3] https://github.com/fenollp/erlscp/blob/master/test/asm_data/unfold3.hrl https://github.com/fenollp/erlscp/blob/master/test/asm_data/... [4] https://github.com/2600hz/kazoo https://github.com/2600hz/kazoo