diff options
author | John Högberg <[email protected]> | 2019-02-26 12:19:44 +0100 |
---|---|---|
committer | John Högberg <[email protected]> | 2019-02-26 16:18:46 +0100 |
commit | ce60cb4e22f03219452b06db0ac7500a5fc884ea (patch) | |
tree | 566f97f480b9a65f6ba9ebf339442c9b62a3341a /lib/eunit/info | |
parent | cd7fa515675adf2551887b6e5ad6ba8d08814413 (diff) | |
download | otp-ce60cb4e22f03219452b06db0ac7500a5fc884ea.tar.gz otp-ce60cb4e22f03219452b06db0ac7500a5fc884ea.tar.bz2 otp-ce60cb4e22f03219452b06db0ac7500a5fc884ea.zip |
beam_jump: Fail label of select_val is unsafe for move elimination
Consider the following code:
bme(Int) ->
TagInt = Int band 2#111,
Tag = case TagInt of
0 -> a; 1 -> b; 2 -> c; 3 -> d;
4 -> e; 5 -> f; 6 -> g; 7 -> h
end,
case Tag of
g -> expects_g(TagInt, Tag);
h -> expects_h(TagInt, Tag);
_ -> Tag = id(Tag), ok
end.
expects_g(6, Atom) -> Atom = id(g), ok.
expects_h(7, Atom) -> Atom = id(h), ok.
The type optimization pass would recognize that TagInt can only be
[0 .. 7], so the first 'case' would select_val over [0 .. 6] and swap
out the fail label with the block for 7.
A later optimization would merge this block with 'expects_h' in the
second case, as the latter is only reachable from the former.
... but this broke down when the move elimination optimization didn't
take the fail label of the first select_val into account. This caused it
believe that the only way to reach 'expects_h' was through the second
case when 'Tag' =:= 'h', which made it remove the move instruction
added in the first case, passing garbage to expects_h/2.
Diffstat (limited to 'lib/eunit/info')
0 files changed, 0 insertions, 0 deletions