| Age | Commit message (Collapse) | Author |
|---|
|
Introduce new "Dbgi" chunk
OTP-14369
|
|
* lukas/erts/list_to_port/OTP-14348:
erts: Add erlang:list_to_port/1 debug bif
erts: Auto-import port_to_list for consistency
erts: Polish off erlang:list_to_ref/1
|
|
|
|
Follow the same pattern as pid_to_list
|
|
By moving to effects_code_generation/1, there is no need
to explicitly remove those options when storing compile
information in the DebugInfo chunk.
|
|
The new Dbgi chunk returns data in the following format:
{debug_info_v1, Backend, Data}
This allows compilers to store the debug info in different
formats. In order to retrieve a particular format, for
instance, Erlang Abstract Format, one may invoke:
Backend:debug_info(erlang_v1, Module, Data, Opts)
Besides introducing the chunk above, this commit also:
* Changes beam_lib:chunk(Beam, [:abstract_code]) to
read from the new Dbgi chunk while keeping backwards
compatibility with old .beams
* Adds the {debug_info, {Backend, Data}} option to
compile:file/2 and friends that are stored in the
Dbgi chunk. This allows the debug info encryption
mechanism to work across compilers
* Improves dialyzer to work directly on Core Erlang,
allowing languages that do not have the Erlang
Abstract Format to be dialyzer as long as they emit
the new chunk and their backend implementation is
available
Backwards compatibility is kept across the board except
for those calling beam_lib:chunk(Beam, ["Abst"]), as the
old chunk is no longer available. Note however the "Abst"
chunk has always been optional.
Future OTP versions may remove parsing the "Abst" chunk
altogether from beam_lib once Erlang 19 and earlier is no
longer supported.
The current Dialyzer implementation still supports earlier
.beam files and such may also be removed in future versions.
|
|
Fixes https://bugs.erlang.org/browse/ERL-406 - a bug introduced in
0377592dc2238f561291be854d2ce859dd9a5fb1
|
|
|
|
The main purpose of these options is compatibility with
old Erlang systems. Since it is no longer possible to
communicate with R15B or earlier, we no longer need the
r12 through r15 options.
|
|
* kill type information only for affected registers in get_map_elements
* bs_get_utf* will produce integers of unicode range
This optimises code created by Elixir compiler, where:
<<x::utf8,_::binary>> when x in 1..10
will compile the guard to
is_integer(X) andalso X >= 1 andalso X =< 10
This allows us to eliminate the is_integer check.
* bs_get_float will produce a float
* allow to carry type information over other bs instructions killing
only the affected registers
* kill only x registers after call_fun and apply instructions
|
|
core_scan will now support and require atoms encoded in UTF-8.
|
|
Rewrite the instruction stream on tagged tuple tests.
Tagged tuples means a tuple of any arity with an atom as its first element.
Typically records, ok-tuples and error-tuples.
from:
...
{test,is_tuple,Fail,[Src]}.
{test,test_arity,Fail,[Src,Sz]}.
...
{get_tuple_element,Src,0,Dst}.
...
{test,is_eq_exact,Fail,[Dst,Atom]}.
...
to:
...
{test,is_tagged_tuple,Fail,[Src,Sz,Atom]}.
...
|
|
Code such as the following:
-record(x, {a}).
f(R, N0) ->
N = N0 / 100,
if element(1, R#x.a) =:= 0 ->
N
end.
would fail to compile with the following message:
m: function f/2+19:
Internal consistency check failed - please report this bug.
Instruction: {fmove,{fr,0},{x,1}}
Error: {uninitialized_reg,{fr,0}}:
This bug was introduced in 348b5e6bee2f.
Basically, the beam_type pass placed the fmove instruction in the
wrong place. Instructions that store to floating point registers and
instructions that read from floating point registers are supposed to
be in the same basic block.
Fix the problem by flushing all floating points instruction
before a call the pseudo-BIF is_record/3, thus making sure that
the fmove instruction is placed in the correct block.
Here is an annotated listing of the relevant part of the .S
file (before the fix):
{test_heap,{alloc,[{words,0},{floats,1}]},2}.
{fconv,{x,1},{fr,0}}.
{fmove,{float,100.0},{fr,1}}.
fclearerror.
{bif,fdiv,{f,0},[{fr,0},{fr,1}],{fr,0}}.
{fcheckerror,{f,0}}.
%% The instruction {fmove,{fr,0},{x,1}} should have
%% been here.
%% Block of instructions expanded from a call to
%% the pseudo-BIF is_record/3. (Expanded in a later
%% compiler pass.)
{test,is_tuple,{f,3},[{x,0}]}.
{test,test_arity,{f,3},[{x,0},2]}.
{get_tuple_element,{x,0},0,{x,2}}.
{test,is_eq_exact,{f,3},[{x,2},{atom,x}]}.
{move,{atom,true},{x,2}}.
{jump,{f,4}}.
{label,3}.
{move,{atom,false},{x,2}}.
{label,4}.
%% End of expansion.
%% The fmove instruction that beam_validator complains
%% about.
{fmove,{fr,0},{x,1}}.
Reported-by: Richard Carlsson
|
|
Binary construction that mixes long literal strings with variables
will make Dialyzer slow. Example:
<<"long string (thousand of characters)",T/binary>>
The string literals in binary construction is translated to one binary
segment per character; all those segments will slow down Dialyzer.
We can speed up Dialyzer if we combine several characters (up to 256)
to a signle segment in the binary. It will also slightly speed up the
compiler.
This optimization will make core listings file with binary strings
harder to read, but they were not that easy to read before this
change.
ERL-308
|
|
This allow languages such as Elixir and LFE to attach
extra chunks to the .beam file without having to parse
the beam file after compilation.
This commit also cleans up the interface to beam_asm,
allowing chunks to be passed from the compiler without
a need to change beam_asm API on every new chunk.
|
|
The new chunk stores atoms encoded in UTF-8.
beam_lib has also been modified to handle the new
'utf8_atoms' attribute while the 'atoms' attribute
may be a missing chunk from now on.
The binary_to_atom/2 BIF can now encode any utf8
binary with up to 255 characters.
The list_to_atom/1 BIF can now accept codepoints
higher than 255 with up to 255 characters (thanks
to Björn Gustavsson).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also slightly refactor the code to simplify the types.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The compiler passes always Options as list to parse_transform/2.
There is no need accept a non-list.
There is also no need to handle an improper Options list. The compiler
itself will crash if the Options list is improper.
|
|
Since Index =:= OldIndex and OldUniq =:= 0, there is no need to
store OldIndex and OldUniq in the internal data structure for the
lambda table.
|
|
* maint:
dialyzer: Compact 'file' annotations in Core code
dialyzer: Try to reduce memory usage
dialyzer: Use less memory when translating contracts
dialyzer: Use maps instaed of dict
dialyzer: Use maps instead of dict for module contracts map
dialyzer: Compress a few more ETS tables
dialyzer: Optimize memory consumption
dialyzer: Reduce memory consumption during 'remote' phase
dialyzer: Update code for finding parallelism
compiler: Do not spawn process when dialyzing
dialyzer: Reduce ETS usage during the typesig phase
dialyzer: Optimize graph condensation
dialyzer: Do not send full PLTs as messages
|
|
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.
|
|
Code with huge literal case expressions such as the following would
compile very slowly:
case "Very long literal string (thousands of characters)..." of
.
.
.
end.
The reason is that in the case optimization each character in the
string would be handled individually. Fix this bug by handling
literals all at once.
|
|
The compiler would keep the data structures for two compiler
passes in memory. That could increase the maximum amount of
memory that the compiler uses, and could also have a negative
impact on performance (terms that would not be used again would be
copied by a garbage collection).
Here is an example that shows how the previous version of the code
could get captured:
a_compiler_pass(Mod, St) ->
case Mod:module(St#compile.code, St#compile.options) of
{ok,Code} ->
{ok,St#compile{code=Code}};
...
The reference to the code from the previous pass will only be released
when St is updated. We can avoid the problem by passing the
current version of the code as a function argument:
a_compiler_pass(Mod, Code0, St) ->
case Mod:module(Code0, St#compile.options) of
{ok,Code} ->
{ok,Code,St};
...
In practice, this change does not seem to significantly speed up
the compiler, but it does not do any harm either. It should help
dialyzer in situations when dialyzer compiles several large modules
at the same time.
|
|
The beam_type may pass move and recalculates test_heap instructions.
The number of live registers are not always the lowest. Minimize the
number of registers by running beam_utils:live_opt/1 one more time.
|
|
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
|
|
|
|
|
