Memory consumption is reduced during the compilation phase by keeping
the Core parse tree shared. In particular the file annotation takes a
lot of memory when not shared.

v3_kernel may produce unwanted and confusing warnings for code that
has been inlined with the new inliner (cerl_inline).  Consider this
code:

-compile(inline).

compute1(X) ->
    add(X, 0).

compute2(X, Y) ->
    add(X, Y).

add(1, 0) ->
    1;
add(1, Y) ->       %% "this clause cannot match..."
    1 + Y;
add(X, Y) ->
    X + Y.

v3_kernel warns because add/2 has been inlined into compute1/1 and only
the first clause in add/2 will match. But the other clauses are needed
when add/2 is inlined into compute2/2, so the user cannot do anything
to eliminate the warning (short of manually inlining add/2, defeating the
purpose of the 'inline' option).

The warning would be reasonable if compute2/2 didn't exist, but it would
be too complicated for the compiler to figure whether a warning make
sense or not.

Therefore, suppress all warnings generated by v3_kernel if cerl_inline
has been run.

ERL-301

Funs must not be created in guards. The instruction for creating
a fun clobbers all X registers, which is a bad thing to do in
a guard.

83199af0263 refactored sys_core_fold to break out the code for the
inline_lists_funcs option to its own module. Unfortunately, it also
accidentally turned off compile-time evaluation of calls to BIFs with
wholly or partial constant arguments.

For example, the code for the following funtion gets much worse
when inline_list_funcs is used:

b() ->
    R0 = #r{},
    R1 = setelement(1+2, R0, "deux"),
    R2 = setelement(1+3, R1, "trois"),
    R3 = setelement(1+5, R2, "cinq"),
    R4 = setelement(1+2, R3, "DEUX"),
    R4.

ERL-285

The following code causes a compiler failure:

first_after(Data, Offset) ->
    case byte_size(Data) > Offset of
	false ->
	    {First, Rest} = {ok, ok},
	    ok;
	true ->
	    <<_:Offset/binary, Rest/binary>> = Data,
	    %% 'Rest' saved in y(0) before the call.
	    {First, _} = match_first(Data, Rest),
	    %% When beam_bsm sees the code, the following line
            %% which uses y(0) has been optimized away.
	    {First, Rest} = {First, Rest},
	    First
    end.

match_first(_, <<First:1/binary, Rest/binary>>) ->
    {First, Rest}.

Here is the error message from beam_validator:

t: function first_after/2+15:
  Internal consistency check failed - please report this bug.
  Instruction: {call,2,{f,7}}
  Error:       {multiple_match_contexts,[{x,1},0]}:

Basically, what happens is that at time of code generation,
the variable 'Rest' is needed after the call to match_first/2
and is therefore saved in y(0). When beam_bsm (a late optimization
pass) sees the code, the use of y(0) following the call
to match_first/2 has been optimized away. beam_bsm therefore
assumes that the delayed sub-binary creation is safe. (Actually,
it is safe, but beam_validator does not realize it.)

The bug was caused by two separate commits:

e199e2471a reduced the number of special cases to handle in BEAM
optimization passed by breaking apart the tail-recursive call
instructions (call_only and call_last) into separate instructions.
Unfortunately, the special handling for tail calls was lost, which
resulted in worse code (i.e. the delayed sub-binary creation
optimization could not be applied).

e1aa422290 tried to compensate, but did so in a way that was not
always safe.

Teaching beam_validator that this kind of code is safe would be
expensive.

Instead, we will undo the damage caused by the two
commits. Re-introduce the special handling of tail-recursive calls in
beam_bsm that was lost in the first commit. (Effectively) revert the
change in the second commit.

ERL-268

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

ab03678e introduced an optimization in the beam_z pass that could
introduce unreachable code in BEAM files (a 'jump' instruction is
removed after a 'raise' instruction, but the code following the
target of the 'jump' is not removed).

Since this situation happens very rarely, there is no point in adding
another pass that can remove unreachable code after beam_z. Instead we
will make sure that beam_validator can skip the unreachable code.
Skipping unreachable code is already done in valfun_1/2 (for
historical reasons), but we will also need to do it in val_dsetel/2.

Moving a fun into a guard may cause code that is not accepted
by beam_validator.

It is not safe to share code between 'catch' blocks.