aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/beam_block.erl
AgeCommit message (Collapse)Author
2014-08-26compiler: Use variables in Map beam assmeblerBjörn-Egil Dahlberg
2014-02-13compiler: Change map instructions for fetching valuesBjörn-Egil Dahlberg
* Combine multiple get values with one instruction * Combine multiple check keys with one instruction
2014-01-28compiler: Fix get_map_element bug with allocateBjörn-Egil Dahlberg
The instruction get_map_element has a faillabel so you may not use the instruction within a allocate/deallocate block.
2014-01-28compiler: Implement different instructions for => and :=Björn Gustavsson
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.
2013-12-13Collect all optimised allocate instructions in beam_blockAnthony Ramine
Any init instruction following an allocate is put in the Inits list of the corresponding alloc tuple.
2013-12-13Properly collect allocate_zero instructions in beam_blockAnthony Ramine
If an allocate_zero instruction is fed to beam_block and the beam_type pass is not used afterwards (e.g. with erlc +no_topt), the 'no_opt' atom will be rejected by beam_flatten.
2013-12-13Properly let floating-point instructions through in the BEAM compilerAnthony Ramine
The compiler shouldn't crash when fed an already-optimised BEAM assembly file.
2013-01-25Update copyright yearsBjörn-Egil Dahlberg
2012-10-10Rewrite select_val and select_tuple_arity to a select instructionBjörn Gustavsson
Eliminate some code bloat.
2012-10-09Rewrite bs_put* instructions to a generic bs_put instructionBjörn Gustavsson
Seven bs_put_* instructions can be combined into one generic bs_put instruction to avoid some code bloat. That will also improve some optimizations (such as beam_trim) that did not handle all bs_put* variants.
2012-10-09Refactor removal of unused labelsBjörn Gustavsson
Since we always want to remove unused labels directly after code generation (whether we'll run the optimization passes or not), we can simplify the code by doing it in beam_a.
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.
2011-12-09Update copyright yearsBjörn-Egil Dahlberg
2011-08-16compiler: Generate line instructionsBjörn Gustavsson
2010-10-12beam_block: Do optimizations in the safe orderBjörn Gustavsson
Moving of allocation instructions upwards in the instruction stream (in order to enable further optimizations) in beam_block, is implemented with the assumption that if a register {x,X} contains a valid term, then all other x register with lower numbers than X also contain valid terms. That assumption is true after code generation. The beam_utils:live_opt/1 optimization, however, may invalidate that assumption. For instance, if a receive statement exports a variable that is used, but the return value of the receive statement is not used, then {x,1} but not {x,0} contains a valid term at the end of the receive statement. If the receive statement is followed by {bif,self,{f,0},[],{x,0}}. {test_heap,NumberOfWords,2}. moving the allocation upwards will produce {test_heap,NumberOfWords,2}. {bif,self,{f,0},[],{x,0}}. which will cause the beam_validator pass to scream loudly that {x,0} is not live at the test_heap instruction. Fix the problem by doing the optimizations in reverse order. Reported-by: Jim Engquist
2010-05-20beam_block: Remove a clause that will never be executedBjörn Gustavsson
Since the introduction of literals in R12B, empty tuples are literals. Thus the put_tuple/2 instruction is always followed by at least one put/1 instruction. Therefore the alloc_may_pass/1 function in beam_block no longer needs a clause for for "put_tuple", because the clause for "put" will always be reached first (since the instruction stream is scanned in reverse execution order). Note that if the compiler would generate a "put_tuple 0 Dst" instruction for some unfathomable reason, we should still be because the run-time system will now refuse to load a module containing such an instruction.
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