| Age | Commit message (Collapse) | Author |
|---|
|
* maint:
dialyzer: Correct the timing of the phase called 'remote'
dialyzer: Optimize expansion of parameters of opaque types
dialyzer: Optimize the expansion of parameterized types somewhat
dialyzer: Improve the handling of recursive parameterized opaque types
dialyzer: Generalize an argument of erl_types:t_from_form()
|
|
* hb/dialyzer/recursive_opaque_types/OTP-12865:
dialyzer: Correct the timing of the phase called 'remote'
dialyzer: Optimize expansion of parameters of opaque types
dialyzer: Optimize the expansion of parameterized types somewhat
dialyzer: Improve the handling of recursive parameterized opaque types
dialyzer: Generalize an argument of erl_types:t_from_form()
|
|
|
|
Opaque recursive parameters are expanded faster.
|
|
Expand parameters when needed only.
The opaqueness is removed from types expanded to any().
|
|
|
|
Add more information about the caller of t_from_form(). Instead of
just the module, also provide name of the type, spec, or record where
the type form resides.
|
|
|
|
* bjorn/compiler/opt/OTP-12951:
beam_validator: Don't allow x(1023) to be used
v3_core: Improve code generation for guards
Move rewriting of select_val to is_boolean from beam_peep to beam_dead
Put 'try' in blocks to optimize allocation instructions
Reorder instructions across try/catch
Delay get_tuple_element instructions until they are needed
Optimize get_tuple_element instructions by moving them forward
beam_block: Improve the move optimizations
beam_block: Clean up optimization of move optimizations
beam_block: Eliminate redundant wasteful call to opt/1
Teach the compiler the 'da' and 'dz' options
|
|
* maint:
hipe/dialyzer: Fix a bug concerning opaque types and keydelete/3
|
|
* hb/hipe/keydelete_fix/OTP-12949:
hipe/dialyzer: Fix a bug concerning opaque types and keydelete/3
|
|
In 45f469ca0890, the BEAM loader started to use x(1023) as scratch
register for some instructions. Therefore we should not allow
x(1023) to be used in code emitted by the compiler.
|
|
When translating guards to Core Erlang, it is sometimes necessary
to add an is_boolean/1 guard test. Here is an example when it is
necessary:
o(A, B) when A or B ->
ok.
That would be translated to something like:
o(A, B) when ((A =:= true) or (B =:= true)) and
is_boolean(A) and is_boolean(B) ->
ok.
The is_boolean/1 tests are necessary to ensure that the guard
fails for calls such as:
o(true, not_boolean)
However, because of a bug in v3_core, is_boolean/1 tests were
added when they were not necessary. Here is an example:
f(B) when not B -> ok.
That would be translated to:
f(B) when (B =:= false) and is_boolean(B) -> ok.
The following translation will work just as well.
f(B) when B =:= false -> ok.
Correct the bug to suppress those unnecessary is_boolean/1 tests.
|
|
We can rewrite more instances of select_val to is_boolean because
it is not necessary that a particular label follows the select_val.
|
|
Put 'try' instructions inside block to improve the optimization
of allocation instructions. Currently, the compiler only looks
at initialization of y registers inside blocks when determining
which y registers that will be "naturally" initialized.
|
|
Simplify further optimizations by moving safe instructions to
before the 'try' or 'catch' instruction.
|
|
When matching tuples, the pattern matching compiler would generate
code that would fetch all elements of the tuple that will ultimately
be used, *before* testing that (for example) the first element is the
correct record tag. For example:
is_tuple Fail {x,0}
test_arity Fail {x,0} 3
get_tuple_element {x,0} 0 {x,1}
get_tuple_element {x,0} 1 {x,2}
get_tuple_element {x,0} 2 {x,3}
is_eq_exact Fail {x,1} some_tag
If {x,2} and {x,3} are not used at label Fail, we can re-arrange the
code like this:
is_tuple Fail {x,0}
test_arity Fail {x,0} 3
get_tuple_element {x,0} 0 {x,1}
is_eq_exact Fail {x,1} some_tag
get_tuple_element {x,0} 1 {x,2}
get_tuple_element {x,0} 2 {x,3}
Doing that may be beneficial in two ways.
If the branch is taken, we have eliminated the execution of two
unnecessary instructions.
Even if the branch is never or rarely taken, there is the possibility
for more optimizations following the is_eq_exact instructions.
For example, imagine that the code looks like this:
get_tuple_element {x,0} 1 {x,2}
get_tuple_element {x,0} 2 {x,3}
move {x,2} {y,0}
move {x,3} {y,1}
Assuming that {x,2} and {x,3} have no further uses in the code
that follows, that can be rewritten to:
get_tuple_element {x,0} 1 {y,0}
get_tuple_element {x,0} 2 {y,1}
When should we perform this optimization?
At the very latest, it must be done before opt_blocks/1 in
beam_block which does the elimination of unnecessary moves.
Actually, we want do the optimization before the blocks have
been established, since moving instructions out of one block
into another is cumbersome.
Therefore, we will do the optimization in a new pass that is
run before beam_block. A new pass will make debugging easier,
and beam_block already has a fair number of sub passes.
|
|
|
|
Here is an example of a move instruction that could not be optimized
away because the {x,2} register was not killed:
get_tuple_element Reg Pos {x,2}
.
.
.
move {x,2} {y,0}
put_list {x,2} nil Any
We can do the optimization if we replace all occurrences of the {x,2}
register as a source with {y,0}:
get_tuple_element Reg Pos {y,0}
.
.
.
put_list {y,0} nil Dst
|
|
The 'move' optimization was relatively clean until GC BIFs
were introduced. Instead of re-thinking the implementation,
the existing code was fixed and patched.
The current code unsuccessfully attempts to eliminate 'move'
instructions across GC BIF and allocation instructions. We can
simplify the code if we give up as soon as we encounter any
instruction that allocates.
|
|
opt_alloc/1 makes a redundant call to opt/1. It is redundant because
the opt/1 function has already been applied to the instruction
sequence prior to calling opt_alloc/1.
|
|
Thanks to ILYA Khlopotov for pointing the bug out.
|
|
* maint:
stdlib: fix a qlc bug introduced in 18.0
|
|
* hb/stdlib/fix_qlc_bug/OTP-12946:
stdlib: fix a qlc bug introduced in 18.0
|
|
As pointed out by roowe, qlc does not handle errors in early compiler
(scanner, parser) well in OTP 18.0.
|
|
Conflicts:
OTP_VERSION
erts/vsn.mk
|
|
|
|
|
|
* ia/ssl/doc/duplicate:
ssl: Remove duplicate documentation
|
|
Correct merge that went wrong.
|
|
* maint:
dialyzer: Fix a bug concerning parameterized opaque types
|
|
* hb/dialyzer/bugfix_opaque_parms/OTP-12940:
dialyzer: Fix a bug concerning parameterized opaque types
|
|
The example is provided by James Fish in
http://erlang.org/pipermail/erlang-questions/2014-December/082204.html.
Note that warnings with text such as "the _ variable breaks
opaqueness" are still possible.
|
|
* maint:
erts: Make sure to unlock status lock when setting process prio
|
|
* lukas/erts/process_priority_unlock/OTP-12943:
erts: Make sure to unlock status lock when setting process prio
|
|
|
|
|
|
* vinoski/stderr-eagain/OTP-12942:
Handle ERRNO_BLOCK in fd_driver async functions
|
|
* lukas/erts/fix_ttsl_binary_leak/OTP-12941:
erts: Fix binary memory leak in ttsl driver
|
|
Several users on erlang-questions have reported problems with recent
releases where output to standard_error causes standard_error_sup to
die from receiving an unexpected eagain error. In the fd_driver,
change the fd_async() function to handle EINTR, and change
fd_ready_async() to handle ERRNO_BLOCK. Add a new test to
standard_error_SUITE to generate output to standard_error and ensure
that standard_error_sup does not die. Thanks to Kota Uenishi for
contributing the test case.
|
|
|
|
* maint:
dialyzer: Use the recently added orddict:orddict/2 type
|
|
|
|
* maint:
ssh: ct:pal -> ct:log in lib/ssh/test
ssh: ssh_trpt_test_lib improvments
ssh: Unicode test improvments
|
|
* hans/ssh/cuddle_tests:
ssh: ct:pal -> ct:log in lib/ssh/test
ssh: ssh_trpt_test_lib improvments
ssh: Unicode test improvments
|
|
|
|
Broken in the parent commit.
|
|
|
|
The diffs are all about adapting to the OTP 18 time interface. The code
was previously backwards compatible, falling back on the erlang:now/0 if
erlang:monotonic_time/0 is unavailable, but this was seen to be a bad
thing in commit 9c0f2f2c. Use of erlang:now/0 is now removed.
|
|
|
