Age | Commit message (Collapse) | Author |
|
Not only variables are allowed as arguments, the name should reflect that.
Change cerl Map argument interface
* cerl:map_arg/1 is more suitable then cerl:map_val/1 in this case.
|
|
b08ffc15e1d9ad105dd6385bbac41c97c09b48bc corrected a bug,
but violated the types by passing a c_apply() when a
c_let() was expected. That happened to work, but Dialyzer
was not amused.
|
|
Code such as apply 'f'/1 () should not be emitted by the Core Erlang inliner.
Commit 1b8ad68361db59477013bf96e485d5293723ff42 added a test case
and correction in v3_core.
|
|
Added coverage of operating map variable.
|
|
Simplify compiler internals and parsing of core format.
|
|
Local fun references look like plain old variables in the Core Erlang
AST but should not be treated as such. Inlining of such expressions is
now restricted to application contexts as a local fun reference should
never occur in a guard.
This is not perfect as it forbids inlining in some safe situations, but
that is still better than a compiler crash.
|
|
|
|
The inliner was ignorant of on_load functions and would discard them
(unless they were exported or referenced).
Noticed-by: Yiannis Tsiouris <[email protected]>
|
|
|
|
* bg/compiler-inliner:
pmod_SUITE: Again test inlining parameterized modules
compiler tests: Cope with missing args in function_clause for native code
compiler tests: Compile a few more modules with 'inline'
Consistently rewrite an inlined function_clause exception to case_clause
compiler tests: Test the 'inline' option better
compiler: Suppress bs_context_to_binary/1 for a literal operand
compiler: Fix binary matching bug in the inliner
sys_core_inline: Don't generated multiple compiler_generated annos
OTP-8552 bg/compiler-inliner
Several problems in the inliner have been fixed.
|
|
A function_clause exception is generated by jumping to a func_info/3
instruction at the beginning of the function. The x registers are
assumed to contain the arguments for the function. That means
that a func_info/3 instruction copied from another function
(or even from the same function if not at the top level) will
not work, so it must be replaced with an instruction that
generates a case_clause exception.
In Core Erlang, a func_info/3 instruction is represented as
a the primop match_fail({function_clause,Arg1,...ArgN}).
The current mechanism that is supposed to replace the
primop match_fail(function_clause) with match_fail(case_clause)
will fail to do that in the following circumstances:
1. If the inliner has inlined a function into itself.
Fix that by having the inliner clear the function_name annotations
on all match_fail primops in functions that are inlined. (To simplify
doing that, the annotation is now on the primop node itself and not on
the 'function_clause' atom inside it.)
2. If the inliner has rewritten the tuple node in the primop node
to a literal (when inlining a function call with literal arguments),
v3_kernel would not recognize the match_fail(function_clause) primop
and would not rewrite it. Fix it by making v3_kernel smarter.
Also simplify the "old" inliner (sys_core_inline) to only clear
the function_name annotations instead of rewriting function_clause
execptions to case_clause execptions itself.
|
|
|