| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
The test was brainfart; integers that don't overlap *AT ALL*
should never meet. It's okay to meet as long as they overlap to
some degree.
|
|
Previously, we would build a large list of used
variables only to compute the intersection. This
commit changes it to compute the unused variables
from given a set which we then subtract from the
original set.
|
|
* maint:
beam_ssa_bsm: Leave ?BADARG_BLOCK alone when cloning fail path
beam_ssa_opt: Do not apply tuple_size optimization outside guards
|
|
* 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
|
|
|
|
Rewriting `tuple_size` to `is_tuple` + `tuple_size` will cause it
not to throw an exception, either crashing the compiler or the
emulator when the code runs.
|
|
* maint:
Fix slow compilation of huge functions
|
|
Some huge functions would compile very slowly because of a bottleneck
in `beam_ssa:def_used/2`. One example is the `cuter_binlib` module in
https://github.com/cuter-testing/cuter. On my computer, this commit
reduces the compilatation time for `cuter_binlib` to 45 seconds down
from more than 4 minutes.
Noticed-by: Kostis Sagonas
|
|
* maint:
Eliminate dialyzer warnings
|
|
Eliminate the Dialyzer warnings shown when the limits in
lib/cerl/erl_types.erl were raised as follows:
-define(TUPLE_TAG_LIMIT, 10).
-define(TUPLE_ARITY_LIMIT, 10).
-define(SET_LIMIT, 64).
|
|
* john/compiler/fun-environment-types/OTP-15896:
compiler: Propagate types of free variables
|
|
* john/compiler/cuddle-type-representation:
compiler: Add common method for literal -> type conversion
|
|
|
|
If the `fun F/A` syntax is used multiple times with the same `F/A`,
(for examle, `fun foo/2`), there would a wrapper function and fun
entry generated for each occurrence.
Using the new support in the OTP 23 runtime system, generate a single
wrapper function and fun entry for each `F/A`. Since there is only one
wrapper function, it can be named based on the name of the function it
calls to faciliate debugging, not based on the function that defines
the fun. For example, the wrapper function for `fun foo/0` will now be
named `-fun.foo/0-'.
|
|
|
|
|
|
* john/compiler/common-type-representation/OTP-15792:
beam_validator: Replace old type representation with beam_types
beam_validator: Subtract types when inferring type test BIFs
beam_call_types: Improve type handling of lists:zip/2 and friends
compiler: Move "known functions" to beam_types
compiler: Break out SSA/beam type definitions into a separate module
beam_ssa_type: Fix meet/join inconsistency
beam_ssa_type: Fix 'band' type determination
beam_validator: Reduce literals to their types
beam_validator: Refactor local call validation
beam_validator: Simplify the match context type
beam_validator: Use integers as tuple element keys
|
|
|
|
cerl: Fix spelling error in a case of ctype()
|
|
This is a temporary solution for basic type tests. We'll need to
handle more-or-less arbitrary values once we introduce union
types, as we need to be able to subtract on tuple_arity tests as
well.
Without this, nearly all "no_opt" test suites will fail to compile
after the validator is migrated to 'beam_types' as a result of
atom subtraction producing 'none' when all alternatives have been
exhausted.
|
|
|
|
|
|
|
|
meet/2 and join/2 were not entirely consistent with each other,
and it was possible to meet integers that didn't overlap,
producing a nonsense result.
None of these can cause issues in the OTP 22 track as far as we can
tell, so a patch doesn't feel necessary at this time.
|
|
The use of meet/2 was incorrect as we weren't guaranteed to provide
a more specific type. This is unlikely to cause errors in OTP 22 as
our ranges were *always* '0 .. X' or 'X .. X', and a meet/2 of two
integers would take the least specific minimum value and most
specific maximum value, making things work by accident.
This is covered by beam_type_SUITE:integers/1, and was made
visible when beam_types:meet/2 was fixed to reject integers that
didn't overlap fully.
|
|
We didn't gain anything by tracking literals exactly, and it
greatly complicates sharing types between passes.
|
|
|
|
There's no need to have an id as part of the type, as the value
reference (through which the type is reached) uniquely identifies
the match context.
|
|
This simplifies a later migration to a unified type format, as the
literal representation may differ between passes, so passing
container types keyed by literals will fail.
|
|
* maint:
erts: Fix bad loader optimization of get_tuple_element
beam_ssa_type: Fix incorrect bitstring unit determination
|
|
* john/compiler/fix-bad-bitstring-type-opt/OTP-15872:
beam_ssa_type: Fix incorrect bitstring unit determination
|
|
The compiler would treat the "Unit" of bs_init instructions as
the unit of the result instead of the required unit of the input,
causing is_binary checks to be wrongly optimized away.
|
|
|
|
* bjorn/compiler/fix-beam_ssa_dead-patch/OTP-15845:
Fix unsafe optimizations where guard tests could be removed
|
|
'bjorng_ghub/bjorn/compiler/fix-beam_ssa_dead-crash/ERL-956/OTP-15848' into maint-22
* bjorng_ghub/bjorn/compiler/fix-beam_ssa_dead-crash/ERL-956/OTP-15848:
Eliminate crash in the beam_ssa_dead compiler pass
|
|
into maint-22
* bjorn/compiler/fix-unloadable-code-patch/ERL-955/OTP-15846:
Fix loading of Core Erlang code for extracting a map element
|
|
* bjorn/compiler/fix-beam_except/ERL-954/OTP-15839:
Fix compiler crash in beam_except
|
|
* bjorn/compiler/fix-unsafe-type-inference/OTP-15838:
Fix unsafe negative type inference
# Conflicts:
# lib/compiler/src/beam_ssa_type.erl
|
