| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
* egil/cuddle-tests:
stdlib: Increase timetrap for rand_SUITE
common_test: Increase timetrap for cth_hooks_SUITE
compiler: Increase timetrap timeouts for lc_SUITE
|
|
Add the option 'deterministic' to make it easier to
achieve reproducible builds.
This option omits the {options,...} and {source,...} tuples in
M:module_info(compile), because those options may contain absolute
paths.
The author of ERL-310 suggested that only compiler options that
may contain absolute paths (such as {i,...}) should be excluded. But I
find it confusing to keep only some options.
Alternatives considered: Always omitting this information. Since this
information has been available for a long time, that would probably
break some workflows. As an example that some people care about
{source,...}, 2d785c07fbf9 made it possible to give a compiler option
to set {source,...}.
ERL-310
|
|
* 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
|
|
|
|
* egil/compiler/opt-maps-pattern-matching/OTP-14072:
compiler: Add regression tests
compiler: Optimize maps pattern matching
compiler: Allow for unaligned match argument in value groups
|
|
|
|
* egil/compiler/maps-warn-repeated-keys/OTP-14058:
compiler: Test repeated map key warnings
compiler: Warn for repeated identical map keys
|
|
|
|
* maint:
Update primary bootstrap
document {yield/nb_yield}() limitation
Suppress warnings from v3_kernel when inlining is turned on
|
|
Guards should use the more efficient 'test' instructions, not 'bif'
instructions. Add a test to make sure that the optimizations don't
degrade.
We do have to keep an exception list for functions where we can't
replace all 'bif' calls with 'test' instructions. We try to keep
that list a short as practically possible.
|
|
Ensure that correct (not necessarily optimal) code is generated for
Core Erlang code not originating from v3_core.
|
|
The guard optimizations in v3_kernel has removed the need for
beam_bool.
|
|
The compiler produces poor code for complex guard expressions with andalso/orelse.
Here is an example from the filename module:
-define(IS_DRIVELETTER(Letter),(((Letter >= $A) andalso (Letter =< $Z)) orelse
((Letter >= $a) andalso (Letter =< $z)))).
skip_prefix(Name, false) ->
Name;
skip_prefix([L, DrvSep|Name], DrvSep) when ?IS_DRIVELETTER(L) ->
Name;
skip_prefix(Name, _) ->
Name.
beam_bool fails to simplify the code for the guard, leaving several 'bif'
instructions:
{function, skip_prefix, 2, 49}.
{label,48}.
{line,[{location,"filename.erl",187}]}.
{func_info,{atom,filename},{atom,skip_prefix},2}.
{label,49}.
{test,is_ne_exact,{f,52},[{x,1},{atom,false}]}.
{test,is_nonempty_list,{f,52},[{x,0}]}.
{get_list,{x,0},{x,2},{x,3}}.
{test,is_nonempty_list,{f,52},[{x,3}]}.
{get_list,{x,3},{x,4},{x,5}}.
{bif,'=:=',{f,52},[{x,1},{x,4}],{x,6}}.
{test,is_ge,{f,50},[{x,2},{integer,65}]}.
{bif,'=<',{f,52},[{x,2},{integer,90}],{x,7}}.
{test,is_eq_exact,{f,51},[{x,7},{atom,false}]}.
{test,is_ge,{f,50},[{x,2},{integer,97}]}.
{bif,'=<',{f,52},[{x,2},{integer,122}],{x,7}}.
{jump,{f,51}}.
{label,50}.
{move,{atom,false},{x,7}}.
{label,51}.
{bif,'=:=',{f,52},[{x,7},{atom,true}],{x,7}}.
{test,is_eq_exact,{f,52},[{x,6},{atom,true}]}.
{test,is_eq_exact,{f,52},[{x,7},{atom,true}]}.
{move,{x,5},{x,0}}.
return.
{label,52}.
return.
We can add optimizations of guard tests to v3_kernel to achive a better result:
{function, skip_prefix, 2, 49}.
{label,48}.
{line,[{location,"filename.erl",187}]}.
{func_info,{atom,filename},{atom,skip_prefix},2}.
{label,49}.
{test,is_ne_exact,{f,51},[{x,1},{atom,false}]}.
{test,is_nonempty_list,{f,51},[{x,0}]}.
{get_list,{x,0},{x,2},{x,3}}.
{test,is_nonempty_list,{f,51},[{x,3}]}.
{get_list,{x,3},{x,4},{x,5}}.
{test,is_eq_exact,{f,51},[{x,1},{x,4}]}.
{test,is_ge,{f,51},[{x,2},{integer,65}]}.
{test,is_lt,{f,50},[{integer,90},{x,2}]}.
{test,is_ge,{f,51},[{x,2},{integer,97}]}.
{test,is_ge,{f,51},[{integer,122},{x,2}]}.
{label,50}.
{move,{x,5},{x,0}}.
return.
{label,51}.
return.
Looking at the STDLIB application, there were 112 lines of BIF calls in guards
that beam_bool failed to convert to test instructions. This commit eliminates
all those BIF calls.
Here is how I counted the instructions:
$ PATH=$ERL_TOP/bin:$PATH erlc -I ../include -I ../../kernel/include -S *.erl
$ grep "bif,'[=<>]" *.S | grep -v f,0
dets.S: {bif,'=:=',{f,547},[{x,4},{atom,read_write}],{x,4}}.
dets.S: {bif,'=:=',{f,547},[{x,5},{atom,saved}],{x,5}}.
dets.S: {bif,'=:=',{f,589},[{x,5},{atom,read}],{x,5}}.
.
.
.
$ grep "bif,'[=<>]" *.S | grep -v f,0 | wc
112 224 6765
$
|
|
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
|
|
* gandrade/fmod/PR-1216/OTP-14000:
Add test cases for math:fmod/2 BIF
Support math:fmod/2 BIF on compiler
Add math:fmod/2 BIF
|
|
|
|
|
|
* maint:
Don't copy funs into guards
|
|
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.
|
|
* maint:
beam_bsm: Eliminate unsafe optimization
|
|
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
|
|
* maint:
Update primary bootstrap
beam_block: Avoid unsafe inclusion of get_map_elements in blocks
|
|
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
|
|
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.
|
|
During development, a bug in beam_utils caused a compiler failure
in xmerl. If the bug reappears, make sure that we catch it when
compiling the compiler test suite.
|
|
|
|
* maint:
beam_validator: Handle unreachable instructions
Turn off parallel make for start scripts Makefile
|
|
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.
|
|
* maint:
[snmp] Correct bug when path to mib contains UTF-8 characters
[ic] Fix but when UTF-8 character in path to idl spec
sys_core_fold: Don't move a fun into a guard
|
|
Moving a fun into a guard may cause code that is not accepted
by beam_validator.
|
|
* bjorn/floor-ceiling/OTP-13692:
Add math:floor/1 and math:ceil/1
Implement the new ceil/1 and floor/1 guard BIFs
|
|
Add math:floor/1 and math:ceil/1 to avoid unnecessary conversions
in floating point expressions. That is, instead of having to write
float(floor(X)) as part of a floating point expressions, we can
write simply math:floor(X).
|
|
Implement as ceil/1 and floor/1 as new guard BIFs (essentially part of
Erlang language). They are guard BIFs because trunc/1 is a guard
BIF. It would be strange to have trunc/1 as a part of the language, but
not ceil/1 and floor/1.
|
|
The filters in a list comprehension can be guard expressions or
an ordinary expressions.
If a guard expression is used as a filter, an exception will basically
mean the same as 'false':
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, element(1, X) =:= some_tag]
%% Returns [{some_tag,42}]
On the other hand, if an ordinary expression is used as a filter, there
will be an exception:
my_element(N, T) -> element(N, T).
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, my_element(1, X) =:= some_tag]
%% Causes a 'badarg' exception when element(1, an_atom) is evaluated
It has been allowed for several releases to override a BIF with
a local function. Thus, if we define a function called element/2,
it will be called instead of the BIF element/2 within the module.
We must use the "erlang:" prefix to call the BIF.
Therefore, the following code is expected to work the same way as in
our second example above:
-compile({no_auto_import,[element/2]}).
element(N, T) ->
erlang:element(N, T).
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, element(1, X) =:= some_tag].
%% Causes a 'badarg' exception when element(1, an_atom) is evaluated
But the compiler refuses to compile the code with the following
diagnostic:
call to local/imported function element/2 is illegal in guard
|
|
sys_pre_expand previously did a lot more work, for example,
translating records and funs, but now is merely a grab bag
of small transformations. Move those transformations to
v3_core.
|
|
Don't only test the case that failed; test it exhaustively.
|
|
* maint:
asn1_test_lib: Compile ASN.1 modules in parallel
Support 'make -j' when compiling ASN.1 modules
[ERL-209] Fix ambiguous_catch_try_state inconsistency error
|
|
It is not safe to share code between 'catch' blocks.
|
|
* josevalim/large-binary-strings/PR-1131/OTP-13794:
Move expansion of strings in binaries to v3_core
|
|
* maint:
Update primary bootstrap
beam_block: Fix potentially unsafe optimization in move_allocates/1
|
|
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 speeds up the compilation of binary literals
with string values in them. For example, compiling
a file with a ~340kB binary would yield the following
times by the compiler:
Compiling "foo"
parse_module : 0.130 s 5327.6 kB
transform_module : 0.000 s 5327.6 kB
lint_module : 0.011 s 5327.8 kB
expand_module : 0.508 s 71881.2 kB
v3_core : 0.463 s 11.5 kB
Notice the increase in memory and processing time
in expand_module and v3_core. This happened because
expand_module would expand the string in binaries
into chars. For example, the binary <<"foo">>, which
is represented as
{bin, 1, [
{bin_element, 1, {string, 1, "foo"}, default, default}
]}
would be converted to
{bin, 1, [
{bin_element, 1, {char, 1, $f}, default, default},
{bin_element, 1, {char, 1, $o}, default, default},
{bin_element, 1, {char, 1, $o}, default, default}
]}
However, v3_core would then traverse all of those
characters and convert it into an actual binary, as it
is a literal value.
This patch addresses this issue by moving the expansion
of string into chars to v3_core and only if a literal
value cannot not be built. This reduces the compilation
time of the file mentioned above to the values below:
Compiling "bar"
parse_module : 0.134 s 5327.6 kB
transform_module : 0.000 s 5327.6 kB
lint_module : 0.005 s 5327.8 kB
expand_module : 0.000 s 5328.7 kB
v3_core : 0.013 s 11.2 kB
|
|
Conflicts:
OTP_VERSION
|
|
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.
|
