| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix a crash in HiPE's lazy code motion pass
|
|
* rickard/hipe-doc:
Update information about HiPE
|
|
|
|
Some change in the BEAM compiler resulted in the creation of basic
blocks that differed from those previously created by the compiler.
As a result, the lazy code motion pass of RTL crashed when compiling
some of the new code.
Crashes were privately reported by @richcarl.
|
|
|
|
This reverts commit fd8e49b5bddceaae803670121b603b5eee8c5c08.
|
|
|
|
|
|
* richcarl/eliminate_lib_module/PR-1786/OTP-15072:
Fix minor issues
Eliminate call to ct:get_progname() in ts_erl_config
Use \n escape instead of integer 10
Move error formatting to erl_error.erl and delete lib.erl
Move extended parse functions in lib.erl to erl_eval.erl
Move lib:eval_str/1 into mod_esi.erl
Remove lib:progname/0
Eliminate call to lib:progname/1 in slave.erl
Add ct:get_progname/0
Remove lib:error_message/2
Remove lib:flush_receive/0
Remove lib:send/2 and lib:sendw/2
Move lib:nonl/1 into yecc.erl
|
|
Introduce is_map_key/2 guard BIF
OTP-15037
|
|
Three of the removed source files don't even compile.
Uncompilable source files cause problems for tools such as
scripts/diffable that want to compile all found source files.
|
|
|
|
This complements the `map_get/2` guard BIF introduced in #1784.
Rationale.
`map_get/2` allows accessing map fields in guards, but it might be
problematic in more complex guard expressions, for example:
foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ...
The `is_list/1` part of the guard could never succeed since the
`map_get/2` guard would fail the whole guard expression. In this
situation, this could be solved by using `;` instead of `or` to separate
the guards, but it is not possible in every case.
To solve this situation, this PR proposes a `is_map_key/2` guard that
allows to check if a map has key inside a guard before trying to access
that key. When combined with `is_map/1` this allows to construct a
purely boolean guard expression testing a value of a key in a map.
Implementation.
Given the use case motivating the introduction of this function, the PR
contains compiler optimisations that produce optimial code for the
following guard expression:
foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok;
foo(_) -> error.
Given all three tests share the failure label, the `is_map_key/2` and
`is_map/2` tests are optimised away.
As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
|
|
The existing test/0 function in erl_types was not being run in the OTP test
suite, and it had not been updated to match the implementation in the
module (maps vs. dict). This commit removes the macros that excluded some
functions, exports the functions now included in the module, and extracts the
test into a new common_test suite, erl_types_SUITE.
|
|
* 'map-get-bif' of git://github.com/michalmuskala/otp:
Introduce map_get guard-safe function
OTP-15037
|
|
Rationale
Today all compound data types except for maps can be deconstructed in guards.
For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are
completely opaque to guards. This means matching on maps can't be
abstracted into macros, which is often done with repetitive guards. It
also means that maps have to be always selected whole from ETS tables,
even when only one field would be enough, which creates a potential
efficiency issue.
This PR introduces an `erlang:map_get/2` guard-safe function that allows
extracting a map field in guard. An alternative to this function would be
to introduce the syntax for extracting a value from a map that was planned
in the original EEP: `Map#{Key}`.
Even outside of guards, since this function is a guard-BIF it is more
efficient than using `maps:get/2` (since it does not need to set up the
stack), and more convenient from pattern matching on the map (compare:
`#{key := Value} = Map, Value` to `map_get(key, Map)`).
Performance considerations
A common concern against adding this function is the notion that "guards
have to be fast" and ideally execute in constant time. While there are
some counterexamples (`length/1`), what is more important is the fact
that adding those functions does not change in any way the time
complexity of pattern matching - it's already possible to match on map
fields today directly in patterns - adding this ability to guards will
niether slow down or speed up the execution, it will only make certain
programs more convenient to write.
This first version is very naive and does not perform any optimizations.
|
|
|
|
Implementation of true asynchronous signaling between processes
|
|
Communication between Erlang processes has conceptually always been
performed through asynchronous signaling. The runtime system
implementation has however previously preformed most operation
synchronously. In a system with only one true thread of execution, this
is not problematic (often the opposite). In a system with multiple threads
of execution (as current runtime system implementation with SMP support)
it becomes problematic. This since it often involves locking of structures
when updating them which in turn cause resource contention. Utilizing
true asynchronous communication often avoids these resource contention
issues.
The case that triggered this change was contention on the link lock due
to frequent updates of the monitor trees during communication with a
frequently used server. The signal order delivery guarantees of the
language makes it hard to change the implementation of only some signals
to use true asynchronous signaling. Therefore the implementations
of (almost) all signals have been changed.
Currently the following signals have been implemented as true
asynchronous signals:
- Message signals
- Exit signals
- Monitor signals
- Demonitor signals
- Monitor triggered signals (DOWN, CHANGE, etc)
- Link signals
- Unlink signals
- Group leader signals
All of the above already defined as asynchronous signals in the
language. The implementation of messages signals was quite
asynchronous to begin with, but had quite strict delivery constraints
due to the ordering guarantees of signals between a pair of processes.
The previously used message queue partitioned into two halves has been
replaced by a more general signal queue partitioned into three parts
that service all kinds of signals. More details regarding the signal
queue can be found in comments in the erl_proc_sig_queue.h file.
The monitor and link implementations have also been completely replaced
in order to fit the new asynchronous signaling implementation as good
as possible. More details regarding the new monitor and link
implementations can be found in the erl_monitor_link.h file.
|
|
Remove unused cerl_messagean module
|
|
Conflicts:
OTP_VERSION
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Eliminate get_list/3 internally in the compiler
|
|
Currently HiPE amd64 assumes the runtime system code is loaded into
the low 2G of the address space. However, this is not the case when
PIE is enabled, it is loaded into a random location. So trampolines
are required to call BIFs, and also we have first to load the address
of sse2_fnegate_mask to a regisiter before xorpd in fchs.
|
|
Make hipe compile option verify_gcsafe the default
|
|
Instructions that produce more than one result complicate
optimizations. get_list/3 is one of two instructions that
produce multiple results (get_map_elements/3 is the other).
Introduce the get_hd/2 and get_tl/2 instructions
that return the head and tail of a cons cell, respectively,
and use it internally in all optimization passes.
For efficiency, we still want to use get_list/3 if both
head and tail are used, so we will translate matching pairs
of get_hd and get_tl back to get_list instructions.
|
|
Consider the following function:
function({function,Name,Arity,CLabel,Is0}, Lc0) ->
try
%% Optimize the code for the function.
catch
Class:Error:Stack ->
io:format("Function: ~w/~w\n", [Name,Arity]),
erlang:raise(Class, Error, Stack)
end.
The stacktrace is retrieved, but it is only used in the call
to erlang:raise/3. There is no need to build a stacktrace
in this function. We can avoid the building if we introduce
an instruction called raw_raise/3 that works exactly like
the erlang:raise/3 BIF except that its third argument must
be a raw stacktrace.
|
|
* maint:
ErLLVM: Preserve precise BEAM tailcall semantics
observer: Fix change accum
Remove double calls
observer: Don't crash for late messages
observer: Optimize tv tab for many tables
|
|
The BEAM compiler chooses not to perform tailcall optimisations for some
calls in tail position, for example to some built-in functions. However,
when the ErLLVM HiPE backend is used, LLVM may choose to perform
tailcall optimisation on these calls, breaking the expected semantics.
To preserve the precise semantics exhibited by BEAM, the 'notail'
marker, present in LLVM since version 3.8, is added to call instructions
that BEAM has not turned into tail calls, which inhibits LLVM from
performing tail-call optimisation in turn.
|
|
* maint:
dialyzer: Fix bsl/2 bug
|
|
* hasse/dialyzer/fix_bsl:
dialyzer: Fix bsl/2 bug
|
|
|
|
which is has been since 3d21f793538927ae88f78504a11dd898e8ca1a7a
|
|
|
|
|
|
Also modified erl_bif_types:infinity_bsl() when called with zero as
first argument. As of writing this, erlang:'bsl'/2 is modified on the
master branch to never fail if called with a huge second argument.
|
|
* maint:
dialyzer: Correct handling of erlang:abs/1
|
|
See also https://bugs.erlang.org/browse/ERL-551.
|
