| Age | Commit message (Collapse) | Author |
|---|
|
When optimizing boolean expressions, it is not always possible
to find a number of live registers for a GC BIF that both preserves
all source registers that will be tested and at the same time
does not include registers that are not initialized.
As currently implemented, we have incomplete information about
the register calculated from the free variables. Some registers
are marked as "reserved". Reserved registers means that we don't
know anything about them; they may or may not be initialized.
As a conservative correction (suitable for a maintenance release), we
will abort the optimization if we find any reserved registers when
calculating the number of live registers. We will not attempt to
improve the information about the registers in this commit.
By examining the coverage when running the existing compiler test
suite we find that the optimization is aborted 15 times (before
adding any new test cases). To put that in perspective, the
optimization is successfully applied 4927 times, and aborted for
other reasons 547 times.
Reported-by: Ulf Norell
Reported-by: Anthony Ramine
|
|
Old versions of the Erlang mode for Emacs used to indent try...catch
strangely - the first clause following the 'catch' would be indented
with one space less than the following clauses.
If we are to use the new Erlang mode when we add more clauses, they
would be indented with one space less than the preceding clauses.
That would look silly.
|
|
The following code could crash the compiler:
f(X = true) when X or true or X -> ok.
Reported-by: Ulf Norell
|
|
* nox/compiler/beam_bool-not_boolean_expr:
Compile BIF calls and operator expressions to Core the same way
Do not try to optimize non-boolean guards
|
|
* nox/compiler/beam_bool-bad-protected:
Properly detect nonboolean protected expressions in beam_bool
|
|
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
|
|
Silly code such as the following could make the compiler crash:
f() when erlang:float(self()); true -> ok.
Reported-by: Ulf Norell
|
|
Reported-by: Ulf Norell
|
|
|
|
|
|
The optimizer of boolean expressions can often reject optimizations
that it does not recognize as safe. For instance, if a boolean
expression was preceded by 'move' instructions that saved x registers
into y registers, it would almost certainly reject the optimization
because it required the y register not be used in the code that
follows.
Fix this problem by allowing identical 'move' instructions that assing
to y registers at the beginning of the old and the optimized code.
While at it, correct the spelling of "preceding".
|
|
* 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
|
|
live_regs/1 folds over a list of tuples, so a clause matching
an element being an empty list can never match.
If the list for some unfathomable reason would contain an empty
list, there will be an internal compiler error and no *.beam file
will be created. Thus this change is safe.
|
|
When scanning a reversed instruction sequence for a function,
it is impossible to reach the end of the list, because each function
must have a fun_info/4 instruction followed by a label/1 instruction
at the beginning, and there is a clause that will handle those
instructions.
If for some unfathomable reason the end of the list would be
reached, with this change there will be an internal compiler error
and no *.beam file will be created. Thus this change is safe.
|
|
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.
|
|
|
