Age | Commit message (Collapse) | Author |
|
This reverts commit 0118046f9bda8dcf3594184fa439b79267db8017.
|
|
|
|
* bjorn/hipe-compilation/OTP-15596:
HiPE: Don't fail the compilation for unimplemented instructions
|
|
|
|
* maint:
Updated OTP version
Prepare release
|
|
|
|
This reverts commit df130102cdeca8d35fec95a0c926fd1cfec54eab.
|
|
|
|
* maint:
dialyzer: Fix maps as parameter of opaque types
dialyzer: Fix key check of lists:key{search,member,find}()
|
|
The clause added for maps in commit 1a7c41be is corrected.
|
|
Replace integers and floats with t_number() since keysearch et al
compare the key (rather than match).
Corrects the commit b3c8e94.
|
|
* maint:
dialyzer: Fix a bug affecting keyfind/keysearch/keymember
|
|
|
|
* maint:
Updated OTP version
Prepare release
|
|
|
|
hipe: Cleanup and fix specs of the hipe module
|
|
hipe_llvm_main: fix tmpfs dir on FreeBSD
|
|
HiPE: Fix check for when ErLLVM is available
|
|
There was a lot of confusion between file vs. module names in the
function specification of the hipe module (as also discovered by #1992)
and this PR cleans up and fixes them.
|
|
* maint:
beam_lib: Remove obsolete module() from the beam() type
hipe: Don't use beam_lib:info/1 with an atom as filename
Honor the max heap size when copying literals after purging
|
|
|
|
The previous check whether ErLLVM could be enabled and/or tested simply
checked whether a suitable version of the LLVM tool chain was present
in the path. Obviously this is not enough: there should also be a check
that we are running in an architecture on which the ErLLVM compiler
has been ported. Fix the function that provides this functionality and
also rename it in order to more appropriately describe what it does.
In principle, this change introduces a backwards incompatibility as the
function is one of those exported by the `hipe' module, but this
function was not documented and the chances that it has been used
somewhere else that the test suite are pretty low (if not zero).
|
|
Rewrite BSM optimizations in the new SSA-based intermediate format
|
|
|
|
|
|
Upstream this patch from FreeBSD Ports:
https://svnweb.freebsd.org/ports/head/lang/erlang-runtime21/files/patch-lib_hipe_llvm_hipe__llvm__main.erl?revision=473434&view=markup
|
|
|
|
|
|
|
|
|
|
Sometimes when building a tuple, there is no way to avoid an
extra `move` instruction. Consider this code:
make_tuple(A) -> {ok,A}.
The corresponding BEAM code looks like this:
{test_heap,3,1}.
{put_tuple,2,{x,1}}.
{put,{atom,ok}}.
{put,{x,0}}.
{move,{x,1},{x,0}}.
return.
To avoid overwriting the source register `{x,0}`, a `move`
instruction is necessary.
The problem doesn't exist when building a list:
%% build_list(A) -> [A].
{test_heap,2,1}.
{put_list,{x,0},nil,{x,0}}.
return.
Introduce a new `put_tuple2` instruction that builds a tuple in a
single instruction, so that the `move` instruction can be eliminated:
%% make_tuple(A) -> {ok,A}.
{test_heap,3,1}.
{put_tuple2,{x,0},{list,[{atom,ok},{x,0}]}}.
return.
Note that the BEAM loader already combines `put_tuple` and `put`
instructions into an internal instruction similar to `put_tuple2`.
Therefore the introduction of the new instruction will not speed up
execution of tuple building itself, but it will be less work for
the loader to load the new instruction.
|
|
If one of the destination registers for get_map_elements is
the same as the map source, extract that element last.
|
|
I did not find any legitimate use of "can not", however skipped
changing e.g RFCs archived in the source tree.
|
|
After this whitespace modification there should be no "can not"s
separated by a newline in the entire OTP repository, so to find
them all a simple git grep will do just fine.
|
|
|
|
|
|
|
|
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.
|