| Age | Commit message (Collapse) | Author |
|---|
|
Simplify compiler internals and parsing of core format.
|
|
With the => and := operators for updating maps, this optimization is
no longer valid.
|
|
The syntax is handled upto v3_kernel where it is reduced to
previous behaviour for construction and updates. Meaning,
the ':=' operator is handled exactly as '=>' operator.
|
|
If a literal key already is present in a Map update the latter should be used.
Warn for previous duplicates in the Map.
|
|
To make it possible to build the entire OTP system, also define
dummys for the instructions in ops.tab.
|
|
Case expressions such as:
case {Expr1,Expr} of
{V1,V2} -> ...
end
are already optimized to not actually build the tuple. Generalize
the optimization to avoid building any kind of composite term,
such as:
case {ok,[A,B]} of
{ok,[X,Y]} -> ...
end
We don't expect programmers to write such code directly, but
inlining can produce such code.
We need to be careful about the warnings we produce. If the case
expression is a literal, it is expected that no warnings should be
produced for clauses that don't match. We must make sure that we
continue to suppress those warnings.
|
|
Compiling programs with very many uses of the "dot notation"
for extracting a record element could be very slow. The reason
is that each extraction of a record element (R#r.a) would first be
transformed to code like this:
case R of
{r,rec0,_,_} -> rec0;
_ -> error({badrecord,r})
end
In Core Erlang, each '_' would be become a new variable. The
resulting code would be optimized by sys_core_fold, but the
optimization process could be very slow.
Profiling shows that sub_del_var/2 was the worst bottleneck, and the
sub_is_val/2 the second worst bottleneck. In both cases, the culprit
is the linear traversal of a very long list (the list of variable
substitutions). Fortunately, there already is a gb_set (the scope)
which contains all variables that are currently live. If a variable is
not known to be live, it is no point in doing the linear operation on
the list.
|
|
The Core Erlang compiler simplifies let expressions by moving them
into their argument when it is another let or a case expression.
It can then perform other optimizations such as removing the let
expressions altogether, sometimes saving BEAM registers later in
the process.
This commit teaches sys_core_fold how to move let expressions into
sequence arguments.
|
|
* nox/fix-seq-opt/OTP-10818:
Add two tests for unused multiple values in effect context
Forbid multiple values in Core Erlang sequence arguments
|
|
It does not make sense to return multiple values from a sequence
argument and the Kernel Erlang passes can't cope with it.
The linting pass now knows how to detect this kind of defunct code and
the Core code folding pass is changed to not generate code like that
when optimizing away multiple-valued lets in effect mode.
Reported-by: José Valim
|
|
|
|
|
|
The following code:
check(<<"string">>, a1) ->
one;
check(_, a2) ->
two;
check(undefined, a3) ->
three.
produces an internal consistency failure:
check: function check/2+17:
Internal consistency check failed - please report this bug.
Instruction: {test,is_eq_exact,{f,7},[{x,0},{atom,undefined}]}
Error: {match_context,{x,0}}:
Actually, in the current implementation of the run-time system,
comparing a match context to an atom is safe, so I briefly considered
updating the beam_validator to let this code pass through. I
abandoned that approach because not all terms would be safe to
compare to a match context, and the implementation might change
in the future.
Therefore, fix this problem by not allowing any matching of non-variables
(in the argument position for binary being matched) following binary
matching. That solution is simple and safe, and since this kind of
code seems to be rare in practice, there is no need to pursue any
more compilicated solution.
Reported-by: Viktor Sovietov
|
|
The inlined lists functions raised an error with only the list instead
of all their given arguments.
|
|
The inlining code for inline_list_funcs silenced the function_clause
error that should occur when calling lists:map(3.5, []).
|
|
The function_clause errors produced by inline_list_funcs should properly
be annotated with their function names to avoid kernel_v3 making them
into case_clauses errors. See v3_kernel:translate_match_fail_1/4.
|
|
Code like `lists:map(fun(X) -> X end, ?C10k), ok` triggers the following
warning:
no_file:none: Warning: a term is constructed, but never used
|
|
|
|
In Core Erlang and later passes, compiler-generated code can be
indicated in two different ways: by negative line numbers and by
a 'compiler_generated' annotation.
Simplify the code and improve coverage by turning negative line
numbers positive and adding a 'compiler_generated' annotation in
the v3_core pass. That means that Core Erlang and latter passes
do not have deal with negative line numbers.
|
|
|
|
opt_guard_try/1 assumed that it was only operating on guards, and
implicitly assumed that any function call was to BIFs without
any side effects.
|
|
In:
case not Expr of ...
we don't have the information to ascertain that Expr is a boolean
expression. Therefore, add the catch-all clause unconditionally.
|
|
The second clause in opt_case_in_let_2/3 attempts to do the same
optimization as opt_bool_case_redundant/1; it will never succeed.
|
|
Also correct the comment in bsm_ensure_no_partition_2/5, and while at
it correct typos in the comment for bsm_nonempty/2.
|
|
|
|
The compiler (sys_core_fold) tries to avoid constructing tuples
in case expressions. The following code:
c(A, B) ->
case {A,B} of
{ok,X} -> X;
{_,_} -> error
end.
will be rewritten so that no tuple is built. If a clause
requires a tuple to be built as in this code:
c(A, B) ->
case {A,B} of
{ok,X} -> X;
V -> V %The tuple will be built here
end.
the tuple will be built in the clause(s) in which it is needed.
If the value returned from the case is not used as in this code:
c(A, B) ->
case {A,B} of
V -> V %Warning: a term is constructed, but never used
end,
ok.
there will be an incorrect warning. Basically, what happens is
that the code is reduced to:
c(A, B) ->
{A,B}, %Warning: a term is constructed, but never used
ok.
and the optimizer sees that the {A,B} tuple can't possibly be used.
Eliminate the warning by adding a 'compiler_generated' annotation
to the tuple.
Reported-by: Kostis Sagonas
|
|
|
|
|
|
The erl_expand_records compiler pass translates the
following code:
h(X) when X#r1.a =:= 1 -> ok.
to (essentially):
h({r1,V1,V2}=X) when element(2, X) =:= 1 -> ok.
Since the guard can only be executed when the pattern matching
has succeeded, we know that the second element in the tuple X
must have been bound to V2. Thus we can eliminate the call
to element/2 like this:
h({r1,V1,V2}=X) when V1 =:= 1 -> ok.
|
|
* bg/compiler-suppress-result-ignored:
compiler tests: Eliminate "result of expression is ignored" warnings
Silence warnings for expressions that are assigned to "_"
OTP-8602 bg/compiler-suppress-result-ignored
It is now possible to suppress the warning in code such as
"list_to_integer(S), ok" by assigning the ignored value "_" like this: "_ =
list_to_integer(S), ok".
|
|
There is currently no zero-cost way to silence the warning
"the result of the expression is ignored", which is issued
for code such as:
list_to_integer(S),
ok
Such code can be useful for assertions or input validation.
Teach the compiler to silence the warning for expressions
that are explicitly assigned to to the "_" variable,
such as:
_ = list_to_integer(S),
ok
Implement it by having the v3_core pass annotate calls in
Core Erlang like this:
let <_> = ( call 'erlang':'list_to_integer'(S) -| ['result_not_wanted'] )
in 'ok'
and modifiy sys_core_fold to suppress the warning for any call
having the annotation.
We deliberately do not make it possible to silence the warnings
for expressions like:
{build,an,unnecessary,term}, ok
or
is_list(L), ok
because we don't know of any real-world scenarios in which that would
be useful.
|
|
|
