diff options
author | Björn Gustavsson <[email protected]> | 2015-02-10 17:10:34 +0100 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2015-03-09 09:59:37 +0100 |
commit | 0a0d39d351fc2008447bb4a5e22e48f429fe4d93 (patch) | |
tree | f6a014f581f0ce41a1df60c56ba11a13db6c603f /erts/info.src | |
parent | e914206e11b439a5794b7a8c3c527af395609ddd (diff) | |
download | otp-0a0d39d351fc2008447bb4a5e22e48f429fe4d93.tar.gz otp-0a0d39d351fc2008447bb4a5e22e48f429fe4d93.tar.bz2 otp-0a0d39d351fc2008447bb4a5e22e48f429fe4d93.zip |
sys_core_fold: Generalize case optimization
For a long time, there has been an optimization for:
{V1,V2,...} = case Expr of Pat -> ... {Val1,Val2,...}; ... end
that avoids building the tuples. The construct looks like this
in Core Erlang:
let <V> = case X of
Pattern -> {Y,Z}
end
in case V of
{A,B} -> A+B
end
The current optimization will try to replace the second 'case'
with a 'let':
let <A,B> = case X of
Pattern -> <Y,Z>
end
in A+B
Simple variations of the construct would prevent the optimizations;
for example this one:
let <V> = case X of
Pattern -> {'ok',Val}
end
in case V of
{ok,Val} -> Val
end
The problem is that the optimization tries to do too much. By
making the optimization do less and have it depend on other
optimizations to finish the job, it will become more powerful.
Thus we can rewrite the code like this:
let <V1,V2> = case X of
Pattern -> <'ok',Val>
end
in let <V> = {V1,V2}
in case V of
{ok,Val} -> Val
end
Note that the second case is unchanged. The other optimizations in the
sys_core_fold module will optimize the second 'case' and eliminate the
building of the tuple.
Diffstat (limited to 'erts/info.src')
0 files changed, 0 insertions, 0 deletions