| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The state without pruned registers was passed on to test_heap
causing the validator to belive registers that aren't live
actually are live.
|
|
|
|
|
|
|
|
|
|
* egil/cuddle-tests:
stdlib: Increase timetrap for rand_SUITE
common_test: Increase timetrap for cth_hooks_SUITE
compiler: Increase timetrap timeouts for lc_SUITE
|
|
Memory consumption is reduced during the compilation phase by keeping
the Core parse tree shared. In particular the file annotation takes a
lot of memory when not shared.
|
|
|
|
|
|
v3_kernel may produce unwanted and confusing warnings for code that
has been inlined with the new inliner (cerl_inline). Consider this
code:
-compile(inline).
compute1(X) ->
add(X, 0).
compute2(X, Y) ->
add(X, Y).
add(1, 0) ->
1;
add(1, Y) -> %% "this clause cannot match..."
1 + Y;
add(X, Y) ->
X + Y.
v3_kernel warns because add/2 has been inlined into compute1/1 and only
the first clause in add/2 will match. But the other clauses are needed
when add/2 is inlined into compute2/2, so the user cannot do anything
to eliminate the warning (short of manually inlining add/2, defeating the
purpose of the 'inline' option).
The warning would be reasonable if compute2/2 didn't exist, but it would
be too complicated for the compiler to figure whether a warning make
sense or not.
Therefore, suppress all warnings generated by v3_kernel if cerl_inline
has been run.
ERL-301
|
|
* valgrind needs a lot of time
|
|
Funs must not be created in guards. The instruction for creating
a fun clobbers all X registers, which is a bad thing to do in
a guard.
|
|
83199af0263 refactored sys_core_fold to break out the code for the
inline_lists_funcs option to its own module. Unfortunately, it also
accidentally turned off compile-time evaluation of calls to BIFs with
wholly or partial constant arguments.
For example, the code for the following funtion gets much worse
when inline_list_funcs is used:
b() ->
R0 = #r{},
R1 = setelement(1+2, R0, "deux"),
R2 = setelement(1+3, R1, "trois"),
R3 = setelement(1+5, R2, "cinq"),
R4 = setelement(1+2, R3, "DEUX"),
R4.
ERL-285
|
|
The following code causes a compiler failure:
first_after(Data, Offset) ->
case byte_size(Data) > Offset of
false ->
{First, Rest} = {ok, ok},
ok;
true ->
<<_:Offset/binary, Rest/binary>> = Data,
%% 'Rest' saved in y(0) before the call.
{First, _} = match_first(Data, Rest),
%% When beam_bsm sees the code, the following line
%% which uses y(0) has been optimized away.
{First, Rest} = {First, Rest},
First
end.
match_first(_, <<First:1/binary, Rest/binary>>) ->
{First, Rest}.
Here is the error message from beam_validator:
t: function first_after/2+15:
Internal consistency check failed - please report this bug.
Instruction: {call,2,{f,7}}
Error: {multiple_match_contexts,[{x,1},0]}:
Basically, what happens is that at time of code generation,
the variable 'Rest' is needed after the call to match_first/2
and is therefore saved in y(0). When beam_bsm (a late optimization
pass) sees the code, the use of y(0) following the call
to match_first/2 has been optimized away. beam_bsm therefore
assumes that the delayed sub-binary creation is safe. (Actually,
it is safe, but beam_validator does not realize it.)
The bug was caused by two separate commits:
e199e2471a reduced the number of special cases to handle in BEAM
optimization passed by breaking apart the tail-recursive call
instructions (call_only and call_last) into separate instructions.
Unfortunately, the special handling for tail calls was lost, which
resulted in worse code (i.e. the delayed sub-binary creation
optimization could not be applied).
e1aa422290 tried to compensate, but did so in a way that was not
always safe.
Teaching beam_validator that this kind of code is safe would be
expensive.
Instead, we will undo the damage caused by the two
commits. Re-introduce the special handling of tail-recursive calls in
beam_bsm that was lost in the first commit. (Effectively) revert the
change in the second commit.
ERL-268
|
|
c2035ebb8b restricted the get_map_elements instruction so that it
could only occur at the beginning of a block. It turns out that
including it anywhere in a block is unsafe.
Therefore, never put get_map_elements instruction in blocks.
(Also remove the beam_utils:join_even/2 function since it is no
longer used.)
ERL-266
|
|
|
|
ab03678e introduced an optimization in the beam_z pass that could
introduce unreachable code in BEAM files (a 'jump' instruction is
removed after a 'raise' instruction, but the code following the
target of the 'jump' is not removed).
Since this situation happens very rarely, there is no point in adding
another pass that can remove unreachable code after beam_z. Instead we
will make sure that beam_validator can skip the unreachable code.
Skipping unreachable code is already done in valfun_1/2 (for
historical reasons), but we will also need to do it in val_dsetel/2.
|
|
Moving a fun into a guard may cause code that is not accepted
by beam_validator.
|
|
Fix some older errors as well.
|
|
It is not safe to share code between 'catch' blocks.
|
|
beam_block has an optimization that only is safe when it is applied
immediately after code generation. That is pointed out in a comment:
NOTE: Moving allocation instructions is only safe because it is done
immediately after code generation so that we KNOW that if {x,X} is
initialized, all x registers with lower numbers are also initialized.
That assumption may not be true after other optimizations, such as
the beam_utils:live_opt/1 optimization.
The new beam_reorder pass added in OTP 19 runs before beam_block.
Therefore, the optimization is potentially unsafe. The optimization
is also unsafe if compilation is started from assembly code in a
.S file.
Rewrite the optimization to make it safe. See the newly added comment
for details.
ERL-202
|
|
|
|
|
|
This reverts commit 105c5b0071056dc062797e58772e098d2a3a4627.
|
|
The following regression was introduced in 19.0:
foo(bar, <<"x">>) -> 1;
foo(_, <<"x">>) -> 2;
foo(_, <<"y">>) -> 3;
foo(_, _) -> fail.
The call foo(bar,<<"y">>) would errorneous return 'fail' instead of 3.
A testcase in match_SUITE has been added to verify this.
|
|
* aronisstav/compiler/fix-compile-forms-spec/PR-1109:
Fix spec of compile:(noenv_)forms/2
|
|
Any exceptions at this point would be of class error, not exit.
|
|
When the compiler fails to write an output file, it used to just print
"error writing file". With this change, it also prints the error
reason:
$ echo "-module(foo)." > foo.erl
$ chmod -w .
$ erlc foo.erl
/tmp/bar/foo.bea#: error writing file: permission denied
|
|
|
|
The input for a call to compile:(noenv_)forms/2 can also be a cerl
module (useful e.g. to resume with 'from_core' after a 'to_core'
compilation).
Internal representations used for 'from_asm' and 'from_beam'
compilation can also be valid, but have no relevant types defined.
|
|
|
|
retrieve the value of the environment variable ERL_COMPILER_OPTIONS
in the same manner as used by file/2, forms/2 and output_generated/2
|
|
* bjorn/compiler/misc:
misc_SUITE: Cover the remaining lines in beam_peep
Avoid the dreaded "no_file" in warnings
Eliminate crash for map updates in guards
beam_block: Eliminate crash in beam_utils
|
|
* jv/compiler/mapsify-rec_env/PR-1082/OTP-13646:
Convert dict() to map() in rec_env.erl
|
|
|
|
Add more filename/line number annotations while translating to
Core Erlang in v3_core, and ensure that sys_core_fold retains
existing annotations. The goal is to avoid that sys_core_fold
generate warnings with "no_file" instead of a filename.
|
|
beam_validator would complain that x(1) is uninitialized
in a test_heap instruction when attempting to compile
the following code with sys_core_fold turned off:
foo(M) when not (M#{true := 0}); [M] ->
ok.
Simplified, the generated BEAM assembly code looked like
this:
test is_map BadMap x(0)
put_map_exact Fail x(0) => x(1) ...
jump BooleanStuff
BadMap:
move ok => x(1)
jump Fail
BooleanStuff:
...
move Boolean => x(2)
jump Build
Fail:
move false => x(2)
Build:
test_heap 2 3 %% x(0), x(1), x(2) must be live.
...
That is, if put_map_exact failed, control would transfer
to the label Fail without initializing x(1).
Fix that by making sure that x(1) is initilized even if
put_map_exact fails:
test is_map BadMap x(0)
put_map_exact BadLbl x(0) => x(1) ...
jump OkLbl
BadLbl:
move ok => x(1)
jump Fail
OkLbl:
jump BooleanStuff
BadMap:
move ok => x(1)
jump Fail
BooleanStuff:
...
move Boolean => x(2)
jump Build
Fail:
move false => x(2)
Build:
test_heap 2 3 %% x(0), x(1), x(2) must be live.
...
Note that this situation is rare, and that other optimization passes
(beam_dead and beam_jump in particular) will clean up this mess.
|
|
This reverts commit e020f75c10410a6943cd055bfa072a2641eab7da.
|
|
|
|
|
|
Somewhat simplified, beam_block would rewrite the target for
the first instruction in this code sequence:
move x(0) => y(1)
gc_bif '+' 1 x(0) => y(0)
move y(1) => x(1)
move nil => x(0)
call 2 local_function/2
The resulting code would be:
move x(0) => x(1) %% Changed target.
gc_bif '+' 1 x(0) => y(0)
move x(1) => y(1) %% Operands swapped (see 02d6135813).
move nil => x(0)
call 2 local_function/2
The resulting code is not safe because the x(1) will be killed
by the gc_bif instruction.
7a47b20c3a cleaned up move optimizations and would reject the
optimization if the target was an X register and an allocating
instruction was found. To avoid this bug, the optimization must be
rejected even if the target is a Y register.
|
|
|
|
We want to find bugs in the compiler during compilation. Validation of
match contexts was weak, which could allow serious bugs in the
generated code to slip through.
|
|
Using a record will make it much easier to add additional information.
|
|
* bjorn/compiler/misc:
Eliminate unsafe use of Y registers
beam_validator: Add is_bitstring/1 as a safe BIF
beam_validator: Remove uncovered line
Teach beam_utils:is_pure_test/1 to handle is_bitstr and is_function2
beam_utils: Simplify handling of 'return' to eliminate uncovered line
beam_jump: Clean up handling of labels before func_info
beam_expect: Correctly handle blocks with multiple allocs
v3_codegen: Don't confuse beam_validator
v3_codegen: Correct code generation for an error/1 call in a guard
beam_receive: Don't crash when encountering nonsensical code
|
|
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.
|
|
beam_validator wrongly complained that the following was
not safe because it didn't know that is_bitstring/1 is safe:
food(Curriculum) ->
[try
is_bitstring(functions)
catch _ ->
0
end, Curriculum].
While we are it, also add a new bif_SUITE test suite to cover some
more code in beam_validator.
|
|
The raise/3 instruction is specially handled, thus there is no need
for bif_type/3 to handle raise/3 (also, the number of arguments was
incorrect, so it could never have matched).
|
