Age | Commit message (Collapse) | Author | |
---|---|---|---|
2013-04-19 | Use a set to store ref registers in beam_receive | Anthony Ramine | |
In some circumstances, as when inlining code, when some optimization passes are disabled or with hand-written but semantically correct Core Erlang or BEAM assembly, a fresh reference may be live in more than one register: ... {allocate_zero,2,2}. ... {call_ext,0,{extfunc,erlang,make_ref,0}}. % Ref in [x0] ... {move,{x,0},{y,0}}. % Ref in [x0,y0] {move,{y,1},{x,0}}. % Ref in [y0] ... {move,{y,0},{x,0}}. % Ref in [x0,y0] {move,{x,0},{y,1}}. % Ref in [x0,y0,y1] {label,5}. {loop_rec,{f,6},{x,0}}. % Ref in [y0,y1] ... {loop_rec_end,{f,5}}. {label,6}. {wait,{f,5}}. ... Pass beam_receive expects a single live register for the ref when it encounters the loop_rec instruction and crashes with the following reason: $ erlc t.S ... crash reason: {{case_clause, {'EXIT', {{case_clause,[{y,1},{y,0}]}, [{beam_receive,opt_recv,5, [{file,"beam_receive.erl"},{line,154}]}, ...]}}}, ...} This commit teaches beam_receive how to use a set of registers instead of a single one when tracking fresh references, thus avoiding the crash. | |||
2013-04-05 | Use erlang:demonitor(Ref, [flush]) where applicable | Loïc Hoguin | |
2012-10-09 | beam_receive: Optimize receives using refs created by spawn_monitor/{1,3} | Björn Gustavsson | |
2012-10-09 | beam_jump: Don't move a block which can be entered via a fallthrough | Björn Gustavsson | |
beam_jump moves short code sequences ending in an instruction that causes an exception to the end of the function, in the hope that a jump around the moved blocked can be replaced with a fallthrough. Therefore, moving a block that is entered via a fallthrough defeats the purpose of the optimization. Also add two more test cases for the beam_receive module to ensure that all lines are still covered. | |||
2010-05-11 | compiler test: Test optimization of receive statements | Björn Gustavsson | |
We don't attempt to run the generated code, but use beam_disasm and check for the presence or absence (as appropriate) of the recv_mark/1 and recv_set/1 instructions. |