| Age | Commit message (Collapse) | Author |
|---|
|
In certain cases of matching with very big binaries, the HiPE compiler
generated code that would fail the match, even in cases that the matching
was successful. The problem was more quite noticeable on 32-bit platforms
where certain integer quantities would be represented as bignums.
Brief summary of changes:
* gen_rtl({bs_skip_bits, ...}, ...) could not handle too large constants.
Previously the constants were truncated to word size.
* hipe_rtl_binary_match:make_size/3 erroneously assumed that the output
of first_part/3 would not overflow when multiplied by 8, which is no
longer true. To maintain full performance, the overflow test is only
performed when BitsVar was a bignum. Thus, the fast path is identical
to before.
* hipe_rtl_binary_match:set_high/2 was assuming that only bits below
bit 27 were ever set in arguments to bs_skip_bits, which is not only
false when the arguments are bignums, but also on 64-bit platforms.
The commit includes a test taken from the bs_match_bin_SUITE.
Most of the credit for finding these HiPE compiler errors and for
creating appropriate fixes for them should go to Magnus Lång.
|
|
|
|
|
|
Only call emasculate_binary if ProcBin.flags is set,
which means it's a writable binary.
|
|
Seen symptom: Hipe compiled code with <<C/utf8, ...>> = Bin does sometimes
not match even though Bin contains a valid utf8 character. There might be
other possible binary matching symptoms, as the problem is not utf8
specific.
Problem: A writable binary was not "emasculated" when the matching started
(as it should) by the hipe compiled code.
Fix: Add a new primop emasculate_binary(Bin) that is called when
a matchstate is created.
ToDo: There are probably room for optimization. For example only call
emasculate_binary if ProcBin.flags is set.
|
|
|
|
Prior to R16B, the bs_match_string instruction worked only for cases
that had a destination variable. As shown by the example below, this
is not always the case and the Dst list can be empty.
test(<<42, _/bits>> = B) -> B.
This fixes a bug reported by Loïc Hoguin (02/12/2013); the original
post used a different code example to illustrate the problem.
While revising the code, a significant clean up was also performed.
|
|
|
