aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/v3_kernel.erl
AgeCommit message (Collapse)Author
2010-05-12Remove opaque declarations from the attributesBjörn Gustavsson
-opaque declarations should not be retained in the attributes (because they will be loaded along with the code and are not useful). While at it, filter away those Dialyzer attributes as early as possible - in v3_kernel.
2010-03-26Consistently rewrite an inlined function_clause exception to case_clauseBjörn Gustavsson
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.
2010-03-25Merge branch 'bg/compiler-remove-r11-support' into devErlang/OTP
* bg/compiler-remove-r11-support: compiler: Don't support the no_binaries option erts: Don't support the put_string/3 instruction compiler: Don't support the no_constant_pool option compiler: Don't support the r11 option test_server: Don't support communication with R11 nodes binary_SUITE: Don't test bit-level binary roundtrips with R11 nodes erts: Test compatibility of funs with R12 instead of R11 OTP-8531 bg/compiler-remove-r11-support
2010-03-22compiler: Don't support the no_constant_pool optionBjörn Gustavsson
The no_constant_pool option was implied by the r11 option. It turns off the usage of the constant (literal) pool, so that BEAM instructions that use constants can be loaded in an R11 system. Since the r11 option has been removed, there is no need to retain the no_constant_pool option.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP