aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/v3_codegen.erl
AgeCommit message (Collapse)Author
2014-01-28compiler: Fix no basic blocks for mapsBjörn-Egil Dahlberg
2014-01-28compiler: Fix stack register reorderingBjörn-Egil Dahlberg
Can now handle {list [reg()]} elements in instructions.
2014-01-28Implement support for maps in the compilerBjörn Gustavsson
To make it possible to build the entire OTP system, also define dummys for the instructions in ops.tab.
2014-01-16compiler: Correct line number in exception from binary constructionBjörn Gustavsson
Reported-by: Stanislav Seletskiy
2012-11-12Merge branch 'maint'Björn Gustavsson
* maint: Fix compiler crash for binary matching and a complicated guard
2012-11-06Fix compiler crash for binary matching and a complicated guardBjörn Gustavsson
The compiler would crash when attempting to compile a function head that did binary matching and had a complex expression using 'andalso' and 'not'. Noticed-by: José Valim
2012-10-09v3_codegen: Combine adjacent bs_match_string instructionsBjörn Gustavsson
In modules with huge functions with many bs_match_string instructions, we can speed up the compilation by combining adjacent bs_match_strings instruction in v3_codegen (as opposed to in beam_block where we used to do it). For instance, on my computer the v3_codegen became more than twice as fast when compiling the re_testoutput1_split_test module in the STDLIB test suites.
2012-10-09v3_codegen: Clarify code generation for binary constructionBjörn Gustavsson
Add some comments to make the code generation for binary construction somewhat clearer. Also get rid of the cg_bo_newregs/2 function that serves no useful purpose. (It was probably intended to undo the effect of cg_live/2, but note that the value passed to cg_bo_newregs/2 has not passed through cg_live/2.)
2012-10-09v3_codegen: Clean up comments and remove out-commented codeBjörn Gustavsson
2012-10-09v3_codegen: Don't duplicate the functionality of cg_reg_arg/2Björn Gustavsson
2012-03-30Update copyright yearsBjörn-Egil Dahlberg
2012-03-14v3_core: Don't put negative line numbers in annotationsBjörn Gustavsson
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.
2012-01-11v3_codegen: Eliminate the special case of 'put' without destinationBjörn Gustavsson
If we let v3_kernel make sure that a 'put' operation always has a destination register, the special case in v3_codegen is not needed.
2012-01-04Eliminate the match_fail primop in v3_kernel and later passesBjörn Gustavsson
In the v3_life pass, it is assumed that a 'match_fail' primop only occur at the top-level and at the end of a function. But this code: do_split_cases(A) -> case A of x -> Z = dummy1; _ -> Z = dummy2, a=b end, Z. will be optimized by sys_core_fold to the following code: 'split_cases'/1 = fun (_cor0) -> let <_cor7,Z> = case _cor0 of <'x'> when 'true' -> < 'dummy1','dummy1' > <_cor6> when 'true' -> %% Here follows a 'match_fail' primop inside %% multiple return values: < primop 'match_fail'({'badmatch','b'}),'dummy2' > end in Z moving the 'match_fail' primop into a "values" construction. In the future, we would like to get rid of the v3_life pass (it is there for historical reasons), so in the mean-time we prefer to not add more code to it by generalizing the handling of 'match_fail'. Since the 'match_fail' primop can be simulated by erlang:error/{1,2}, the simplest solution is to translate 'match_fail' to a call to erlang:error/{1,2} in v3_kernel and remove the handling of 'match_fail' in v3_life and v3_codegen. It is tempting to get rid of 'match_fail' also in the Core Erlang format, but there are two issues: - Removing the support for 'match_fail' completely may break tools that generate Core Erlang code. We should not do that in a minor release. - There is no easy way to generate a 'function_clause' exception that will remain correct if it will be inlined into another function. (Calling "erlang:error(function_clause, Args)" is fine only if it is not inlined into another function.) A good solution probably involves introducing new instructions, which is better done in a major release. Noticed-by: Håkan Matsson Minimized-test-case-by: Erik Søe Sørensen
2011-08-16compiler: Generate line instructionsBjörn Gustavsson
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2011-02-07v3_codegen: Use the latest instance of StBjörn Gustavsson
By accident a previous instance of St is used, which is harmless in this case, but leads to worse quality of the generated code.
2010-09-23Fix compiler crash when constructing zero-size binary segmentsBjörn Gustavsson
Code such as foo(A) -> <<A:0>>. would cause a compiler crash.
2010-03-26compiler: Suppress bs_context_to_binary/1 for a literal operandBjörn Gustavsson
The inliner can cause illegal uses of the bs_context_to_binary/1 instruction, such as: bs_context_to_binary {literal,"string"} or bs_context_to_binary {integer,1} Remove the bs_context_to_binary/1 instruction if the operand is not a register (it is clearly not needed).
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