diff options
author | Björn Gustavsson <[email protected]> | 2016-09-13 08:43:44 +0200 |
---|---|---|
committer | Björn Gustavsson <[email protected]> | 2016-09-26 16:20:40 +0200 |
commit | 7169258d1315b86622093e1f14faf2267c9c448e (patch) | |
tree | c9a4053abf8bd9c0d744c3229f95220ba83a3479 /erts/obj.debug | |
parent | ac3bbbe932f2e547d93ebdc7c3bf4c0e542f30bd (diff) | |
download | otp-7169258d1315b86622093e1f14faf2267c9c448e.tar.gz otp-7169258d1315b86622093e1f14faf2267c9c448e.tar.bz2 otp-7169258d1315b86622093e1f14faf2267c9c448e.zip |
sys_core_fold: Improve case optimization
The optimization that avoids building a tuple in a case
expression would not work if any clause matched a tuple
as in the following example:
f(A, B) ->
case {A,B} of
{<<X>>,Y} ->
{X,Y}
end.
The generated Core Erlang code would look like this (note
the tuples in the case expression and the pattern):
'f'/2 =
fun (_cor1,_cor0) ->
case {_cor1,_cor0} of
<{#{#<X>(8,1,'integer',['unsigned'|['big']])}#,Y}>
when 'true' ->
{X,Y}
.
.
.
end
It is expected that the code should look like this (note
that tuples have been replaced with "values"):
'f'/2 =
fun (_cor1,_cor0) ->
%% Line 5
case <_cor1,_cor0> of
<#{#<X>(8,1,'integer',['unsigned'|['big']])}#,Y> ->
{X,Y}
.
.
.
end
While at it, also fix bugs in the handling of pattern with
aliases. The bindings were produced in the wrong order (creating
'let's with referring to free variables), but in most cases
the incorrect bindings were discarded later without causing any
harm.
Diffstat (limited to 'erts/obj.debug')
0 files changed, 0 insertions, 0 deletions