| Age | Commit message (Collapse) | Author |
|---|
|
* maint:
beam_validator: Values referenced by other values must be merged
|
|
into maint
* john/compiler/fix-delayed-type-inference/OTP-15954/ERL-995:
beam_validator: Values referenced by other values must be merged
|
|
Optimize is_subset and is_disjoint in cerl_sets
|
|
* maint:
Avoid extremely long compilation times for huge functions
|
|
bjorng/bjorn/compiler/fix-slow-beam_ssa_dead/ERL-1014/OTP-15966
Avoid extremely long compilation times for huge functions
|
|
* maint:
Fix compiler crash when compiling with +no_type_opt
Eliminate a crash in the type optimizer pass
|
|
https://github.com/bjorng/otp into maint
OTP-15970
* 'bjorn/compiler/length-misuse/ERL-1013' of https://github.com/bjorng/otp:
Eliminate a crash in the type optimizer pass
|
|
https://github.com/bjorng/otp into maint
OTP-15969
* 'bjorn/compiler/fix-no_type_opt/ERL-997' of https://github.com/bjorng/otp:
Fix compiler crash when compiling with +no_type_opt
|
|
Compiling this example takes less than a second for OTP 21:
-define(B, {?A,?A,?A,?A,?A}).
-define(C, {?B,?B,?B,?B,?B}).
-define(D, {?C,?C,?C,?C,?C}).
-define(E, {?D,?D,?D}).
f() -> ?E = foo:bar().
The compilation time for OTP 22 is about 10 seconds. Most of the
time is spent in `beam_ssa_dead`.
This commit introduces several optimizations to bring the compilation
time down to about a second.
The most important of those optimizations is limiting the effort spent
searching forward for a joining point for the success and failure
labels for a two-way branch. This change is helped by the change of
representation of variable sets from `ordsets` to `cerl_sets`.
https://bugs.erlang.org/browse/ERL-1014
|
|
* maint:
Fix unsafe code sharing
|
|
* bjorn/compiler/fix-unsafe-sharing/OTP-15963:
Fix unsafe code sharing
|
|
If the `no_type_opt` option was given, the compiler would crash when
attempting to compile containing with a `try`...`after` construct,
such as this code:
foo() ->
try
make_ref()
after
ok
end.
To avoid having this bug re-appear, test the `no_type_opt` option
in the test suites.
https://bugs.erlang.org/browse/ERL-997
|
|
https://bugs.erlang.org/browse/ERL-1013
|
|
|
|
The new implementation use maps iterators and are more
perfomant in banchmarks by roughly 10%. More importantly,
the iterators approach allow us to short-circuit and abort
early.
fold and filter have also been changed to use iterators.
We could simply delegate to the maps' functions, but
inlining the implementation allows us to skip a double
anonymous function dispatch.
|
|
* john/compiler/improve-validator-type-inference/ERL-998:
beam_validator: Improve type inference on inequality
beam_validator: Remove redundant calls to infer_types
|
|
This is a more proper fix for ERIERL-348. We used to think that
we wouldn't need to update the type of a variable that's no
longer referenced by a register ("dead value"), but the attached
test case pokes a hole in that assumption.
To summarize, the result of '=:='/2 is kept alive longer than one
of its arguments, which gets pruned in a state merge leaving us
with nothing to work on when we finally compare the result. This is
fine for most operations since there's no point in (say) updating
the size of a tuple we can no longer reach, but '=:='/2 updates
the types of both arguments and we risk missing out on important
information when either of them is gone.
This commit fixes the problem by merging all values that are
*reachable* from a register, rather than just those that *exist*
in a register, ensuring that all values stay around at least as
long as they're needed.
|
|
* maint:
Updated OTP version
Prepare release
# Conflicts:
# OTP_VERSION
# make/otp_version_tickets_in_merge
|
|
* maint-22:
Updated OTP version
Prepare release
# Conflicts:
# make/otp_version_tickets
|
|
Both sides need to be inferred, and we should infer as if we've
made an exact match when we know that LHS is single-valued. This
was done for select_val, but we failed to do so for is_ne_exact
et al.
|
|
|
|
* maint:
compiler: Fix compiler crash introduced by OTP-15952
|
|
into maint
* john/compiler/fix-bad-try_catch-recv-fix/OTP-15953/ERL-999:
compiler: Fix compiler crash introduced by OTP-15952
|
|
|
|
An assertion in code generation would fail when the common exit
block was ?BADARG_BLOCK, as some operations expect to always "fail"
directly to that block (= throw an exception) and we had inserted
a dummy block in between.
Other operations could also get funny fail labels, jumping to
blocks that immediately jumped to {f,0}, but these were all cleaned
up by beam_jump, sweeping the bug under the rug.
|
|
* maint:
Updated OTP version
Prepare release
# Conflicts:
# OTP_VERSION
# make/otp_version_tickets_in_merge
|
|
* maint-22:
Updated OTP version
Prepare release
# Conflicts:
# make/otp_version_tickets
|
|
|
|
maint-22
* john/compiler/fix-fail-path-exceptions-bsm/OTP-15946:
beam_ssa_bsm: Leave ?BADARG_BLOCK alone when cloning fail path
|
|
* john/compiler/fix-unsafe-tuple_size-opt/OTP-15945:
beam_ssa_opt: Do not apply tuple_size optimization outside guards
|
|
* maint:
compiler: Fix broken 'receive' in try/catch blocks
|
|
* john/compiler/fix-try_catch-receives/OTP-15952:
compiler: Fix broken 'receive' in try/catch blocks
|
|
This fix is rather ugly and tacked-on, but I'm not comfortable
refactoring the pass in an emergency patch.
|
|
Extend the compiler's type representation
|
|
Eagerly extracting elements can be quite problematic now that we
have union types. Consider the following:
0:
%% _0 is {ok, #record{}} | {error,atom()}
_1 = get_tuple_element _0, literal 0
_2 = get_tuple_element _0, literal 1
switch _1, label 0, [ { literal ok, label 1 }, { literal error, label 2 } ]
1:
%% _0 is known to be {ok,#record{}} here
2:
%% _0 is known to be {error,atom()} here
The type pass is clever enough to see that _0 has the types noted
above, but because the type of _2 is set in the first block where
we didn't have that information yet, it's still #record{} | atom()
in both branches.
Sinking these instructions to when they are used greatly improves
the type information in many cases, but it does have a few
limitations and using it in both of the above branches would take
us back to square one.
|
|
If we know that the checked value is a singleton at the fail
block, it's safe to infer types as if we've made a direct
comparison against that value.
|
|
Collect unused vars instead of used ones
|
|
|
|
|
|
Consider the type `{ok, #record{}} | {error,atom()}`; in our
current type representation this will be flattened down to
`{ok | error, #record{} | atom()}`, which is fairly useful but has
no connection between the elements. Testing that the first element
is 'error' lets us skip checking that it's 'ok' on failure, but the
second element is still `#record{} | atom()` and we'll eventually
need to test that, even though it can only be a `#record{}`.
Another example would be `false | {value, term()}`, the return
value of lists:keyfind/3, which we're forced to flatten to `any`
since there's nothing in common between an atom and a tuple.
Union types let us express these types directly, greatly improving
type optimization.
|
|
|
|
Whenever there's a type conflict during type inference we know
that the branch will not be taken. Previously we'd go down the
branch with garbage type information which would crash in some
cases.
There's no test case for the crashes because the ones I've found
require union types to happen, and we already have good coverage
once they're in place.
|
|
When the compiler is smart enough to figure out that something
will always succeed, it will get rid of the failure branch, but
the inverse has not been possible because liveness optimization
could end up removing the instruction altogether (since it's never
used on the failure path), which is not okay when exceptions are in
the picture.
To prevent exception-generating instructions from being optimized
away when their branches are, we introduce a dummy instruction
that refers to the result on the failure path, ensuring that it
won't be optimized away.
|
|
|
|
The idea was to look at the argument types to see if we could get
rid of failure branches, but this didn't turn out to be useful and
the function ended up being a copy of erl_bifs:is_safe/3, so we may
as well get rid of it.
|
|
|
|
The previous implementation of infer_types had a general problem
with negative inference, and relied on an ugly hack to make simple
subtraction work for type tests. This gets rid of that hack and
makes it possible to subtract types on tuple size and element
comparisons.
|
|
|
|
|
|
|
