| Age | Commit message (Collapse) | Author |
|---|
|
Add -MMD option to erlc
OTP-14830
|
|
|
|
The compile option makedep_side_effect, erlc -MMD, instructs
the compiler to emit dependencies and continue to compile
as normal.
|
|
d8d07a7593d811 that added the to_dis option to the compiler no longer
works when merged to master. That is because of 79f28cfd8df1b7
that removed some unused code in erts_debug.
Fix this by adding a new function erts_debug:dis_to_file/2 and
use it from compile module where we have access to the filename
(in beam_listing we only have an opened file).
|
|
Conflicts:
lib/compiler/src/beam_listing.erl
|
|
|
|
* maint:
Recognize 'deterministic' when given in a -compile() attribute
Conflicts:
lib/compiler/src/beam_asm.erl
|
|
The v3_life pass does not do enough to be worth being its own
pass. Essentially it does two things:
* Calculates life-time information starting from the annotations
that v3_kernel provides. That part can be moved into v3_codegen.
* Rewrites the Kernel Erlang records to similar plain tuples
(for example, #k_cons{hd=Hd,tl=Tl} is rewritten to {cons,Hd,Tl}).
That rewriting is not needed and can be eliminated.
|
|
This allows compilers built on top of the compile module
to attach external compilation metadata to the compile_info
chunk.
For example, Erlang uses this chunk to store the compiler
version. Elixir and LFE may augment this by also adding
their own compiler versions, which can be useful when
debugging.
The deterministic option does not affect the user supplied
compile_info. It is therefore the responsibility of external
compilers to guarantee any added information does not violate
the determinsitic option, if such option is supported.
Finally, this code moves the building of the compile_info
options to the compile module instead of beam_asm, moving
all of the option mangling code to a single place.
|
|
The goal of this pass is to find values that are built from
patterns and generate aliases for those values to remove
pressure from the GC. For example, this code:
example({ok, Val}) ->
{ok, Val}.
shall become:
example({ok, Val} = Tuple) ->
Tuple.
Currently this pass aliases tuple and cons nodes made of literals,
variables and other cons. The tuple/cons may appear anywhere in the
pattern and it will be aliased if used later on.
Notice a tuple/cons made only of literals is not aliased as it may
be part of the literal pool.
|
|
* hasse/unicode_atoms/OTP-14285:
compiler: Handle (bad) Unicode parse transform module names
kernel: Improve handling of Unicode filenames
stdlib: Handle Unicode atoms in ms_transform
stdlib: Improve Unicode handling of the Erlang parser
stdlib: Handle unknown compiler options with Unicode
stdlib: Handle Unicode macro names
stdlib: Correct Unicode handling in escript
dialyzer: Improve handling of Unicode
parsetools: Improve handling of Unicode atoms
stdlib: Handle Unicode atoms when formatting stacktraces
stdlib: Add more checks of module names to the linter
stdlib: Handle Unicode atoms better in io_lib_format
stdlib: Handle Unicode atoms in c.erl
|
|
|
|
As part of sys_core_fold, variables involved in bit syntax
matching would be annotated when it would be safe for a later
pass to do the delayed sub-binary creation optimization.
An implicit assumption regarding the annotation was that the
code must not be further optimized. That assumption was broken
in 05130e48555891, which introduced a fixpoint iteration
(applying the optimizations until there were no more changes).
That means that a variable could be annotated as safe for
reusing the match context in one iteration, but a later iteration
could rewrite the code in a way that would make the optimization
unsafe.
One way to fix this would be to clear all reuse_for_context
annotations before each iteration. But that would be wasteful.
Instead I chose to fix the problem by moving out the annotation
code to a separate pass (sys_core_bsm) that is run later after
all major optimizations of Core Erlang has been done.
|
|
compile:forms/1,2 is documented to return:
{ok,ModuleName,BinaryOrCode}
However, if one of the options 'from_core', 'from_asm', or
'from_beam' is given, ModuleName will be returned as [].
A worse problem is that is that if one those options are
combined with the 'native' option, compilation will crash.
Correct compile:forms/1,2 to pick up the module name from
the forms provided (either Core Erlang, Beam assembly code,
or a Beam file).
Reported here: https://bugs.erlang.org/browse/ERL-417
|
|
|
|
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.
|
|
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.
|
|
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]}.
...
|
|
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).
|
|
|
|
* 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.
|
|
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.
|
|
* 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
|
|
|
|
* maint:
Update primary bootstrap
document {yield/nb_yield}() limitation
Suppress warnings from v3_kernel when inlining is turned on
|
|
The guard optimizations in v3_kernel has removed the need for
beam_bool.
|
|
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
|
|
* rickard/time-unit/OTP-13831:
Replace usage of deprecated time units
|
|
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.
|
|
|
|
* 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
|
|
Use case in compile.erl is cryptographical so use
crypto:strong_rand_bytes/1 instead.
Use case in test suite is not cryptographical so use
other test instead.
|
|
|
|
compile:forms/1,2 will crash when the current working directory has
been deleted. Fix that problem, and while we are at it, also stop
including {source,""} in module_info() when no source code file is
given.
Reported-at: http://bugs.erlang.org/browse/ERL-113
Reported-by: Adam Lindberg
|
|
Slightly speed up 'erlc' by pre-loading the modules used
by the compiler. Write a test case to ensure that the correct
set of modules are loaded.
|
|
|
|
|
|
The 'random' module is used to pad the end of a block with random
bytes. The appropriate function to use in this case
crypto:rand_bytes/1.
|
|
In the future we might want to add more bit syntax optimizations,
but beam_block is already sufficiently complicated. Therefore, move
the bit syntax optimizations out of beam_block into a separate
compiler pass called beam_bs.
|
|
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.
|
|
Add the 'da' option to create a list after the beam_a pass. Seeing
how the code looks after beam_a, but before the blocks have been
established, is sometimes useful.
For symmetry, add the 'dz' option, even though it is just a synonym
for 'S'.
|
|
|
|
In a5d724cf240a, a debug option for running eprof on a specific
compiler pass was added. That commit added a direct call to the eprof
module in the tools application, and therefore the test case
otp_SUITE:runtime_dependencies/1 would fail because xref would find a
call to the tools application, but tools is not listed as a runtime
dependency in compiler.app.
Since the 'eprof' option is only likely to be used by compiler
maintainers, we don't want a real dependency to the tools application.
Therefore, use c:appcall/4 to hide the call to the eprof module (and
to report the error nicely if the tools application is missing).
|
