aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/beam_utils.erl
AgeCommit message (Collapse)Author
2018-03-01beam_utils: Correct is_killed/3, is_killed_at/3, is_used/3Björn Gustavsson
is_killed/3 and is_killed_at/3 could return 'true' even if the register was referenced by an allocation instruction. Somehow, that does not seem to have caused any problems yet.
2018-02-12Fix unsafe use of 'allocate' where 'allocate_zero' should be usedBjörn Gustavsson
The more aggressive optimizations of 'allocate_zero' introduced in cb6fc15c35c7e could produce unsafe code such as the following: {allocate,0,1}. {bif,element,{f,0},[{integer,1},{x,0}],{x,0}}. The code is not safe because if element/2 fails, the runtime system may scan the stack and find garbage that looks like a catch tag, and would most probably crash. Fix the problem by making beam_utils:is_killed/3 be more conservative when asked whether a Y register will be killed. Also fix an unsafe move upwards of an allocation instruction in beam_block.
2018-01-26Eliminate get_list/3 internally in the compilerBjörn Gustavsson
Instructions that produce more than one result complicate optimizations. get_list/3 is one of two instructions that produce multiple results (get_map_elements/3 is the other). Introduce the get_hd/2 and get_tl/2 instructions that return the head and tail of a cons cell, respectively, and use it internally in all optimization passes. For efficiency, we still want to use get_list/3 if both head and tail are used, so we will translate matching pairs of get_hd and get_tl back to get_list instructions.
2018-01-22Don't build a stacktrace if it's only passed to erlang:raise/3Björn Gustavsson
Consider the following function: function({function,Name,Arity,CLabel,Is0}, Lc0) -> try %% Optimize the code for the function. catch Class:Error:Stack -> io:format("Function: ~w/~w\n", [Name,Arity]), erlang:raise(Class, Error, Stack) end. The stacktrace is retrieved, but it is only used in the call to erlang:raise/3. There is no need to build a stacktrace in this function. We can avoid the building if we introduce an instruction called raw_raise/3 that works exactly like the erlang:raise/3 BIF except that its third argument must be a raw stacktrace.
2018-01-12Merge pull request #1680 from bjorng/bjorn/compiler/beam_blockBjörn Gustavsson
Run beam_block a second time
2018-01-11Prepare beam_utils to run again after beam_splitBjörn Gustavsson
beam_utils:live_opt/1 is currently only run early (from beam_block). Prepare it to be run after beam_split when instructions with failure labels have been taken out of blocks. While we are it, also improve check_liveness/3. That will improve the optimizations in beam_record (replacing tuple matching instructions with an is_tagged_tuple instruction).
2018-01-11beam_utils: Correct handling of liveness for select_valBjörn Gustavsson
Since the select_val instruction never transfer directly to the next instruction, the incoming live registers should be ignored. This bug have not caused any problems yet, but it will in the future if we are to run the liveness optimizations again after the optimizations in beam_dead and beam_jump.
2018-01-11Refactor '%live' and '%def' annotationsBjörn Gustavsson
The annotations in the optimizing passes currently looks like this: {'%live',NumRegistersUsed,RegistersUsedBitmap} {'%def',RegistersDefinedBitmap} (NumRegistersUsed is no longer used.) When I attempted to extend some optimizations, I found that I had to add additional clauses to tolerate/handle both types of annotations. That problem would only get worse if any more annotations are added in the future. To simplify annotation handling, this commit wraps both types of annotations in a {'%anno',_} tuple: {'%anno',{used,RegistersUsedBitmap}} {'%anno',{def,RegistersDefinedBitmap}} The '%live' annotation has been renamed to 'used' to make it somewhat clearer what it means, and the unused NumRegistersUsed part of the old annotation has been removed. Alternatives considered: My first attempt was to wrap the annotation in a 'set' tuple so that there would only be 'set' tuples in a block. For example: {set,[],[],{anno,{live,RegistersUsedBitmap}}} It was not as convenient as expected. Annotations often need to be handled specially from other instructions in a block. When they are wrapped in a 'set' tuple, they can very easily be handled incorrectly or passed on to the next pass. That causes subtle errors or worse code, and it can be difficult to debug. Therefore, my conclusion is that annotations should be distinct from other instructions, to make it obvious when one have missed to handle an annotation.
2018-01-10Correct beam_utils:combine_heap_needs/2Björn Gustavsson
In 21dd6e55877832, beam_utils:combine_heap_needs/2 stopped wrapping an allocation list in an {alloc,...} tuple. That was not noticed because the faulty heap need created in beam_block was discarded by beam_type.
2018-01-10Correct beam_utils:is_killed/3Björn Gustavsson
beam_utils:is_killed/3 could incorrectly indicate that a register was killed, when in fact it was referenced by an instruction that did a GC.
2017-12-20Reduce register shuffling in receive clausesBjörn Gustavsson
Handle a few more instructions in beam_utils. That will allow beam_reorder to reorder more instructions, delaying get_tuple_element instructions and reducing register shuffling in receive clauses.
2017-12-18Merge pull request #1658 from bjorng/bjorn/compiler/delay-stackframeBjörn Gustavsson
Delay creation of stack frames
2017-12-15beam_utils: Add usage/3Björn Gustavsson
To avoid having to call both is_killed/3 and is_not_used/3, add usage/3 to answer both questions in one call.
2017-12-15beam_utils: Add anno_defs/1Björn Gustavsson
Add beam_utils:anno_defs/1 which will add an annotation to the beginning of each block indicating which X registers that are defined. Having that information can improve some optimizations.
2017-12-15beam_utils: Improve precision for is_not_used/3Björn Gustavsson
2017-12-14beam_utils: Refactor combine_alloc_lists() to cover more linesBjörn Gustavsson
There are four uncovered lines in combine_heap_needs/2 and combine_alloc_lists/2. There is no way to reach starting from Erlang source code using the standard compiler. However, they can be reached starting from BEAM assembly code, so we don't want to remove them. We could add a test case that covers the lines using assembly code, but an easier solution is to rewrite the code in a more generic way using sofs so that the code can be covered with existing test cases.
2017-12-13beam_util: Fix bug in is_not_used/3Björn Gustavsson
01835845579e9 fixed some problems, but introduced a bug where is_not_used/3 would report that a register was not used when it in fact was.
2017-11-30Add syntax in try/catch to retrieve the stacktrace directlyBjörn Gustavsson
This commit adds a new syntax for retrieving the stacktrace without calling erlang:get_stacktrace/0. That allow us to deprecate erlang:get_stacktrace/0 and ultimately remove it. The problem with erlang:get_stacktrace/0 is that it can keep huge terms in a process for an indefinite time after an exception. The stacktrace can be huge after a 'function_clause' exception or a failed call to a BIF or operator, because the arguments for the call will be included in the stacktrace. For example: 1> catch abs(lists:seq(1, 1000)). {'EXIT',{badarg,[{erlang,abs, [[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20|...]], []}, {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]}, {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,431}]}, {shell,exprs,7,[{file,"shell.erl"},{line,687}]}, {shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]}, {shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}]}} 2> erlang:get_stacktrace(). [{erlang,abs, [[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, 23,24|...]], []}, {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]}, {erl_eval,expr,5,[{file,"erl_eval.erl"},{line,431}]}, {shell,exprs,7,[{file,"shell.erl"},{line,687}]}, {shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]}, {shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}] 3> We can extend the syntax for clauses in try/catch to optionally bind the stacktrace to a variable. Here is an example using the current syntax: try Expr catch C:E -> Stk = erlang:get_stacktrace(), . . . In the new syntax, it would look like: try Expr catch C:E:Stk -> . . . Only a variable (not a pattern) is allowed in the stacktrace position, to discourage matching of the stacktrace. (Matching would also be expensive, because the raw format of the stacktrace would have to be converted to the cooked form before matching.) Note that: try Expr catch E -> . . . is a shorthand for: try Expr catch throw:E -> . . . If the stacktrace is to be retrieved for a throw, the 'throw:' prefix must be explicitly included: try Expr catch throw:E:Stk -> . . .
2017-11-27Recognize 'nil' as a literal in beam_utils:bif_to_test/3Björn Gustavsson
beam_utils:bif_to_test/3 is supposed to never put a literal operand as the first operand in is_eq_exact or is_ne_exact, but 'nil' was not recognized as a literal.
2017-10-11Optimize try/catch that ignores the return valueBjörn Gustavsson
If a try/catch is used to ignore the potential exception caused by some expression with a side effect such as: try side_effect() catch _Class:_Reason -> ok end, . . . the generated code will be wasteful: try YReg TryLabel %% call side_effect() here try_end Yreg jump GoodLabel TryLabel: try_case YReg %% try_case has set up registers as follows: %% x(0) -> error | exit | throw %% x(1) -> reason %% x(2) -> raw stack trace data GoodLabel: %% This code does not use any x registers. There will be two code paths that both end up at GoodLabel, and the try_case instruction will set up registers that are never used. We can do better by replacing try_case with try_end to obtain this code: try YReg TryLabel %% call side_effect() here try_end Yreg jump GoodLabel TryLabel: try_end YReg GoodLabel: The jump optimizer (beam_jump) can further optimize this code like this: try YReg TryLabel %% call side_effect() here TryLabel: try_end YReg
2017-09-08Optimise equality comparisonsMichał Muskała
* In both loader and compiler, make sure constants are always the second operand - many passes of the compiler assume that's always the case. * In loader rewrite is_eq_exact with same arguments to skip the instruction and with different constants move one to an x register to maintain the properly outlined above. * The same (but in reverse) is done with the is_ne_exact, where we rewrite to an unconditional jump or add a move to an x register. * All of the above allow to replace is_eq_exact_fss with is_eq_exact_fyy and is_ne_exact_fss with is_ne_exact_fSS as those are the only possibilities left.
2017-08-22Merge branch 'maint'Lukas Larsson
2017-08-22Merge branch ↵Lukas Larsson
'john/compiler/fail-labels-in-blocks-otp-18/ERIERL-48/OTP-14522' into maint * john/compiler/fail-labels-in-blocks-otp-18/ERIERL-48/OTP-14522: compiler: Fix live regs update on allocate in validator Take fail labels into account when determining liveness in block ops Conflicts: lib/compiler/src/beam_utils.erl
2017-08-12Introduce beam_utils:replace_labels/4Michał Muskała
2017-08-07Take fail labels into account when determining liveness in block opsJohn Högberg
2017-01-12beam_utils: Add types and specsBjörn Gustavsson
2016-12-09beam_type: Minimize number of regs in test_heap instructionsBjörn Gustavsson
The beam_type may pass move and recalculates test_heap instructions. The number of live registers are not always the lowest. Minimize the number of registers by running beam_utils:live_opt/1 one more time.
2016-11-18Remove beam_boolBjörn Gustavsson
The guard optimizations in v3_kernel has removed the need for beam_bool.
2016-10-05Merge branch 'maint'Björn Gustavsson
* maint: Update primary bootstrap beam_block: Avoid unsafe inclusion of get_map_elements in blocks
2016-10-05beam_block: Avoid unsafe inclusion of get_map_elements in blocksBjörn Gustavsson
c2035ebb8b restricted the get_map_elements instruction so that it could only occur at the beginning of a block. It turns out that including it anywhere in a block is unsafe. Therefore, never put get_map_elements instruction in blocks. (Also remove the beam_utils:join_even/2 function since it is no longer used.) ERL-266
2016-09-21Simplify beam_utilsBjörn Gustavsson
When beam_utils was first written, it did not have the functions for testing whether a register was not used. Those were added later, in sort of a hacky way. Also, is_killed*() and is_not_used*() for Y registers would return the same answer. Fix that to make the API more consistent (an Y register can only be killed by a deallocate/1 instruction). We will need to change beam_trim to call beam_utils:is_not_used/3 instead of beam_utils:is_killed/3.
2016-05-30Teach beam_utils:is_pure_test/1 to handle is_bitstr and is_function2Björn Gustavsson
The 'is_bitstr' and 'is_function2' tests are pure. The corresponding BIFs have different names; thus the default call to erl_internal:new_type_test/2 is not sufficient.
2016-05-25beam_utils: Simplify handling of 'return' to eliminate uncovered lineBjörn Gustavsson
Y registers are killed by the deallocate/1 instruction, so there is no need to handle Y register in the return/1 instruction in check_liveness/3. There is also no need to keep check_liveness_live_ret/3 since it is only used in one place.
2016-05-13beam_utils: Correct break in conventions for split_even/1 and join_even/1Björn Gustavsson
Exported functions in this file should appear at the top of the file. Also add missing spaces after commas.
2016-05-13beam_utils: Remove clause checking for illegal set/4 instructionBjörn Gustavsson
I can't remember that clause ever trigger during development. Remove it to eliminated an uncovered line.
2016-05-13beam_utils: Simplify the return value for check_liveness/3Björn Gustavsson
check_liveness/3 returns {unknown,State} if an instruction is not handled. All callers will handle 'unknown' the same way as 'used'. Therefore, we can simplify the code and improve the coverage if we return {used,State} instead of {unknown,State}.
2016-05-13beam_utils: Remove unused codeBjörn Gustavsson
2016-05-13beam_utils: Let code_at/2 fail if the label does not existBjörn Gustavsson
All callers only calls code_at/2 for existing labels and they don't handle the return value 'none'.
2016-05-13beam_utils: Remove unused handling of try/3 in live_opt/4Björn Gustavsson
30cc5c902d moved try/3 instruction inside blocks, so the clause for handling try/3 in live_opt/4 is never executed.
2016-05-13beam_utils: Correct translation of BIFs to testsBjörn Gustavsson
Two lines were never covered, because '[]' was used instead of 'nil'.
2016-04-18Merge branch 'bjorn/compiler/misc-opt'Björn Gustavsson
* bjorn/compiler/misc-opt: v3_kernel: Construct literal lists properly Use the register map in %live in beam_utils:is_killed_block/2 Teach beam_utils to check liveness for put_map instructions beam_peep: Help out beam_jump
2016-04-14Use the register map in %live in beam_utils:is_killed_block/2Björn Gustavsson
In 1f0ae04d374, a complete register map was introduced in the %live instructions thar are added by beam_utils:live_opt/1. Use the register map to improve beam_utils:is_killed_block/2.
2016-04-11Teach beam_utils to check liveness for put_map instructionsBjörn Gustavsson
2016-03-15update copyright-yearHenrik Nord
2015-08-21Delay get_tuple_element instructions until they are neededBjörn Gustavsson
When matching tuples, the pattern matching compiler would generate code that would fetch all elements of the tuple that will ultimately be used, *before* testing that (for example) the first element is the correct record tag. For example: is_tuple Fail {x,0} test_arity Fail {x,0} 3 get_tuple_element {x,0} 0 {x,1} get_tuple_element {x,0} 1 {x,2} get_tuple_element {x,0} 2 {x,3} is_eq_exact Fail {x,1} some_tag If {x,2} and {x,3} are not used at label Fail, we can re-arrange the code like this: is_tuple Fail {x,0} test_arity Fail {x,0} 3 get_tuple_element {x,0} 0 {x,1} is_eq_exact Fail {x,1} some_tag get_tuple_element {x,0} 1 {x,2} get_tuple_element {x,0} 2 {x,3} Doing that may be beneficial in two ways. If the branch is taken, we have eliminated the execution of two unnecessary instructions. Even if the branch is never or rarely taken, there is the possibility for more optimizations following the is_eq_exact instructions. For example, imagine that the code looks like this: get_tuple_element {x,0} 1 {x,2} get_tuple_element {x,0} 2 {x,3} move {x,2} {y,0} move {x,3} {y,1} Assuming that {x,2} and {x,3} have no further uses in the code that follows, that can be rewritten to: get_tuple_element {x,0} 1 {y,0} get_tuple_element {x,0} 2 {y,1} When should we perform this optimization? At the very latest, it must be done before opt_blocks/1 in beam_block which does the elimination of unnecessary moves. Actually, we want do the optimization before the blocks have been established, since moving instructions out of one block into another is cumbersome. Therefore, we will do the optimization in a new pass that is run before beam_block. A new pass will make debugging easier, and beam_block already has a fair number of sub passes.
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-29beam_utils: Re-use the local helper function drop_labels/1Björn Gustavsson
In 8470558, the drop_labels/1 function was added to beam_utils as a minor optimization. Since the function is already available, we might as well use it in index_label/3 too.
2015-04-29beam_utils: Teach check_liveness/3 to understand get_map_elementsBjörn Gustavsson
Understanding get_map_elements improves the stack trimming done by beam_trim.
2015-04-29beam_utils: Be less conservative about liveness for exit instructionsBjörn Gustavsson
beam_utils used to be overly conservative about liveness for exit instructions such as: call_ext erlang:exit/1 beam_utils would consider all y registers to be used, to avoid overwriting a catch or try tag. That does not seem to be a real risk. However, we miss opportunities for stack trimming if we consider y registers used by an exit instruction.
2015-04-22beam_utils: Optimize index_labels_1/2Björn Gustavsson
The execution time for beam_utils:index_labels_1/2 is among the longest in the beam_bool, beam_bsm, beam_receive, and beam_trim compiler passes. Therefore it is worthwhile to do the minor optimization of replacing a call to lists:dropwhile/2 with a special-purpose drop_labels function.