| Age | Commit message (Collapse) | Author |
|---|
|
It's time that we have a dedicated test suite for beam_bool.
|
|
Two test cases were not actually run. Even if their main purpose is to
ensure that the compiler doesn't crash, we always try to also run the
test case (when practial) to also ensure that the generated code is
correct.
|
|
|
|
|
|
andor_SUITE:check/2 function can be replaced with pattern matching.
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
|
|
Optimize away 'not' in sys_core_fold instead of in beam_block
and beam_dead, as we can do a better job in sys_core_fold.
I modified the test suite temporarily to never turn off Core Erlang
modifications and looked at the coverage. With the new optimizations
active in sys_core_fold, the code in beam_block and beam_dead did not
find a single 'not' that it could optimize. That proves that the new
optimization is at least as good as the old one. Manually, I could
also verify that the new optimization would optimize some variations
of 'not' that the old one would not handle.
|
|
Introduce access functions to hide the low-level details of how
type information is implemented.
|
|
I have spent too much time lately waiting for 'cover' to finish,
so now its time to optimize the running time of the tests suite
in coverage mode.
Basically, when 'cover' is running, the test suites would not
run any tests in parallel. The reason is that using too many
parallel processes when running 'cover' would be slower than
running them sequentially. But those measurements were made
several years ago, and many improvements have been made to
improve the parallelism of the run-time system.
Experimenting with the test_lib:p_run/2 function, I found that
increasing the number of parallel processes would speed up the
self_compile tests cases in compilation_SUITE. The difference
between using 3 processes or 4 processes was slight, though,
so it seems that we should not use more than 4 processes when
running 'cover'.
We don't want to change test_lib:parallel/0, because there is
no way to limit the number of test cases that will be run in
parallel by common_test. However, there as test suites (such as
andor_SUITE) that don't invoke the compiler at run-time. We can
run the cases in such test suites in parallel even if 'cover'
is running.
|
|
The following code could crash the compiler:
f(X = true) when X or true or X -> ok.
Reported-by: Ulf Norell
|
|
Expressions such as erlang:'or'(bar, true) can make beam_bool crash if it tries
to optimize them, as this code is not quite really written by users, no attempt
to rewrite them more efficiently should be done, for simplicity's sake.
Reported-by: Ulf Norell
|
|
|
|
beam_utils:is_not_used_at/3 could be very slow for complex guards,
because the cached result for previously encountered labels were
neither used nor updated within blocks.
Reported-by: Magnus Müller
|
|
|
|
Run testcases in parallel will make the test suite run slightly
faster. Another reason for this change is that we want more testing
of parallel testcase support in common_test.
|
|
In 3d0f4a3085f11389e5b22d10f96f0cbf08c9337f (an update to conform
with common_test), in all test_lib:recompile(?MODULE) calls, ?MODULE
was changed to the actual name of the module. That would cause
test_lib:recompile/1 to compile the module with the incorrect
compiler options in cloned modules such as record_no_opt_SUITE,
causing worse coverage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* bg/compiler-cover-and-clean:
v3_life: Remove clause that cannot match in match_fail/3
v3_life tests: Cover exception handling code in v3_life:function/1
beam_type: Remove redundant clause
v3_core tests: Cover make_bool_switch_guard/5
v3_core tests: Cover handling of pattern aliases
v3_core: Remove a clause in is_simple/1 that cannot match
v3_core: Remove unused support for generating compilation errors
Remove stray support for the put_literal/2 instruction
Remove stray support for the bs_bits_to_bytes2/2 instruction
Remove the bs_bits_to_bytes/3 instruction
Cover handling of 'math' BIFs
beam_bool: Remove a clause in live_regs/1 that cannot match
beam_bool: Cover handling of bs_context_to_binary in initialized_regs/2
beam_bool: Remove a clause in initialized_regs/2 that cannot match
beam_block: Remove a clause that will never be executed
erts: Stop supporting non-literal empty tuples
compile: Remove code that is only executed on Solaris
Do not cover-analyze core_scan
core_SUITE_data: Don't ignore *.core files in this directory
OTP-8636 bg/compiler-cover-and-clean
|
|
|
|
The following code (by Simon Cornish)
bad(XDo1, XDo2, Do3) ->
Do1 = (XDo1 =/= []),
Do2 = (XDo2 =/= []),
CH1 = if Do1 == true;
Do1 == false,Do2==false,Do3 == blah ->
ch1;
true ->
no
end,
CH2 = if Do1 == true;
Do1 == false,Do2==false,Do3 == xx ->
ch2;
true ->
no
end,
{CH1,CH2}.
is optimized by beam_bool even though the optimization is not
safe. The trouble is that an assignment to {y,0} no longer
occurs on all paths leading to its use.
The bug is in dst_regs/2 which is supposed to return a set
of all registers assigned in a code block, but it ignores
registers assigned in 'move' instructions.
Fix the bug by taking 'move' instructions into account. This change
is safe since it can only cause more registers to be added
to the MustBeKilled and MustBeUnused sets in ensure_opt_safe/6,
which means that it can only cause the optimization to be turned
off for code that used to be optimized.
|
|
The following code crashes beam_bool:
bad(XDo1, XDo2, Do3) ->
Do1 = (XDo1 =/= []),
Do2 = (XDo2 =/= []),
if Do1 =:= true;
Do1 =:= false, Do2 =:= false, Do3 =:= delete ->
no
end.
(Reported by Simon Cornish; minimized by Kostis Sagonas.)
For the moment fix the bug in the simplest and safest way possible
(basically, instead of crashing just don't do the optimization).
In a future major release (e.g. R14), the following improvements
could be considered:
* In beam_bool, it should be possible to move the Do1 and Do2
expressions to the pre-block and still optimize the expression
in the 'if' statement.
* In sys_core_fold, it should be possible to eliminate the
try/catch around the guard expression in the 'if', because
none of the guard tests can actually fail.
|
|
|
