| Age | Commit message (Collapse) | Author |
|---|
|
hipe_icode_call_elim could in some cases replace an #icode_call{} with
control flow with a move instruction. This would break the control flow
graph invariants and cause a crash.
|
|
This fixes a HiPE bug reported on erlang-questions on 2/11/2016.
The BEAM to ICode tranaslation of the bs_match_string instruction,
written long ago for binaries (i.e., with byte-sized strings), tried
to do a `clever' translation of even bit-sized strings using a HiPE
primop that took a `Size' argument expressed in *bytes*.
ICode is not really the place to do such a thing, and moreover there
is really no reason for the HiPE primop not to take a Size argument
expressed in *bits* instead. This commit changes the `Size' argument
to be in bits, postpones the translation of the bs_match_string primop
Fixed in a pair-programming/debugging session with @margnus1.
until RTL and does a proper translation using bit-sized quantities there.
|
|
|
|
|
|
|
|
|
|
Seems like halt/2 should be a member of this club.
|
|
* Implemented removal of maps:is_key/2 calls of which the result is
known in a new pass during the typed phase, called
hipe_icode_call_elim.
* Added the option icode_call_elim that enables the
hipe_icode_call_elim pass, and made it default for o2.
|
|
* henrik/update-copyrightyear:
update copyright-year
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It was assumed in hipe_icode_fp:filter_map/3 that either all
predecessors would have an up-to-date ("assigned") tagged copy, or none
of them.
This is temporarily false during the fixpoint loop in
basic_floats:test_icode_type_crash_2/0, which exercises the
all_args_equal(Bindings) =:= true branch, that would previously
erroneously end up in the 'false' branch, which is what caused the crash
in that case.
This is likewise only temporarily false during the fixpoint loop in
basic_floats:test_icode_type_crash/0, but that case instead exercises
the 'false' branch, justifying the inclusion of both tests.
|
|
|
|
A previous commit introduced a change that exposed dead code in this
module and caused dialyzer warnings. This dead code was taken out.
While at it, performed some code refactoring in the handling of the
bs_get_integer primop.
|
|
Conflicts:
erts/emulator/beam/beam_emu.c
|
|
|
|
This allows us to compile bs_match_int_SUITE with HiPE without a
system_limit crash.
|
|
Expressions like <<0:(fun(X)->X end(anka))>> would fail with 'badarith'
in HiPE, but 'badarg' in BEAM.
hipe_beam_to_icode was attempting to optimise the amount of code
generated by letting the arithmetic error propagate instead of
catching it. However, since it was emitting a block to throw 'badarg' in
that case anyway, we can just reuse it to achieve just as compact code
that behaves exactly like BEAM.
|
|
The unit size field was previously completely discarded when lowering
this instruction from BEAM to Icode.
This feature was previously missing and expressions such as <<0,
<<1:1>>/binary>> would succeed construction when compiled with HiPE.
|
|
The bulk of the changes concerns cleanups and code refactorings concerning
record constructions that assigned 'undefined' to record fields whose type
did not contain this value. See commit 8ce35b2.
While at it, some new type definitions were introduced and type names were
used instead of record type notation. Minor code cleaups were also done.
|
|
|
|
According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:
<<>>#{a=>42}
That was not implemented in the OTP 17.
José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:
http://erlang.org/pipermail/erlang-questions/2015-February/083588.html
This commit implement better errors from map operations similar
to his suggestion.
When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:
{badmap,Term}
This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.
When a map operation requires a key that is not present in a map,
the following exception will be raised:
{badkey,Key}
José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.
For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.
If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.
|
|
|
|
|
|
Namely, extend the HiPE tagging scheme info, properly handle the translation
of the (is_)map type test to Icode and RTL and support handling of the map()
type in the type system.
While at it, also performed some clean up of things that needed small fixes.
|
|
|
|
|
|
|
|
|
|
The types array(), dict(), digraph(), gb_set(), gb_tree(), queue(),
set(), and tid() have been deprecated. They will be removed in OTP 18.0.
Instead the types array:array(), dict:dict(), digraph:graph(),
gb_set:set(), gb_tree:tree(), queue:queue(), sets:set(), and ets:tid()
can be used. (Note: it has always been necessary to use ets:tid().)
It is allowed in OTP 17.0 to locally re-define the types array(), dict(),
and so on.
New types array:array/1, dict:dict/2, gb_sets:set/1, gb_trees:tree/2,
queue:queue/1, and sets:set/1 have been added.
|
|
To reproduce the error:
$ echo '-module(hello).' > hello.erl
$ erl
1> c(hello, [native,{hipe,[no_remove_comments]}]).
[...]
<HiPE (v 3.10.2.1)> Error: [hipe:834]: ERROR: {{case_clause,
{icode_comment,call_ext_only}},
[{hipe_icode,successors,1,
[{file,"hipe_icode.erl"},
{line,1444}]},
[...]
|
|
|
|
|
|
|
|
* ks/hipe-cleanup-escaping/OTP-11031:
Loosen the assumptions of code that handles escaping functions
|
|
The HiPE compiler implicitly relied on the assumption that a function
will never appear as both exported and also used as function closure.
This was true because the BEAM compiler prior to R16B created module
local anonymous functions for each closure. A proposed change to the
BEAM compiler invalidates this invariant, so in order to accommodate
for this change there needs to be a change of how the set of possibly
escaping functions is computed.
While doing this, the code was simplified by taking out a boolean()
tag that indicated whether a function is a closure or exported and
also slightly cleaned up the affected modules.
|
|
|
|
|
|
|
|
|
|
The following module produced erroneous results when compiled with HiPE:
-module(a).
-export([foo/1]).
foo(X) when is_number(X) ->
is_integer(X).
Running:
1> c(a).
2> a:foo(0).
true
3> hipe:c(a).
4> a:foo(0).
false % *** WRONG ***
The problem was that the 'number' case for the `hipe_icode:type_test/1`
was going to the default case where the argument was determined as being
something other than an integer. Thanks to Sebastian Egner and Johannes
Weißl for bringing the bug into attention. Fixed on the day it was reported.
|
|
|
|
Conflicts:
lib/diameter/autoconf/vxworks/sed.general
xcomp/README.md
|
|
|
|
|
|
|
