| Age | Commit message (Collapse) | Author |
|---|
|
'john/compiler/fail-labels-in-blocks-otp-19/ERIERL-48/OTP-14522' into maint-20
* john/compiler/fail-labels-in-blocks-otp-19/ERIERL-48/OTP-14522:
compiler: Fix live regs update on allocate in validator
Take fail labels into account when determining liveness in block ops
|
|
|
|
* maint:
Update copyright-year
Conflicts:
lib/dialyzer/src/dialyzer.hrl
lib/dialyzer/src/dialyzer_options.erl
lib/dialyzer/test/opaque_SUITE_data/src/recrec/dialyzer.hrl
lib/dialyzer/test/opaque_SUITE_data/src/recrec/dialyzer_races.erl
lib/hipe/icode/hipe_icode.erl
lib/hipe/main/hipe.erl
lib/hipe/main/hipe.hrl.src
lib/hipe/main/hipe_main.erl
|
|
|
|
When beam_utils was first written, it did not have the functions
for testing whether a register was not used. Those were added
later, in sort of a hacky way.
Also, is_killed*() and is_not_used*() for Y registers would
return the same answer. Fix that to make the API more consistent
(an Y register can only be killed by a deallocate/1 instruction).
We will need to change beam_trim to call beam_utils:is_not_used/3
instead of beam_utils:is_killed/3.
|
|
If the Core Erlang optimization were turned off (using no_copt),
the optimization passes for Beam assembly could generate unsafe
code that did not initialize all Y registers before (for example)
a call instruction.
To fix this, beam_dead should not attempt to remove stores to Y
registers. That is not safe if there is an exception-generating
instruction inside a try...catch block.
|
|
By first adding a call to error/1 to each uncovered line,
QuickCheck could find test cases that would cover the lines.
|
|
beam_utils_SUITE didn't exist when the two test cases were written.
|
|
|
|
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.
|
|
|
