aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test
AgeCommit message (Collapse)Author
2017-02-12Add extra_chunks option to compileJosé Valim
This allow languages such as Elixir and LFE to attach extra chunks to the .beam file without having to parse the beam file after compilation. This commit also cleans up the interface to beam_asm, allowing chunks to be passed from the compiler without a need to change beam_asm API on every new chunk.
2017-02-01Merge branch 'josevalim/atu8-chunk/PR-1078/OTP-14178'Björn Gustavsson
* josevalim/atu8-chunk/PR-1078/OTP-14178: Add new AtU8 beam chunk
2017-01-30Add new AtU8 beam chunkJosé Valim
The new chunk stores atoms encoded in UTF-8. beam_lib has also been modified to handle the new 'utf8_atoms' attribute while the 'atoms' attribute may be a missing chunk from now on. The binary_to_atom/2 BIF can now encode any utf8 binary with up to 255 characters. The list_to_atom/1 BIF can now accept codepoints higher than 255 with up to 255 characters (thanks to Björn Gustavsson).
2017-01-25Update test cases for erlang:hash/2 removalBjörn-Egil Dahlberg
2017-01-17Merge branch 'maint'Björn-Egil Dahlberg
2017-01-17Merge branch 'egil/cuddle-tests' into maintBjörn-Egil Dahlberg
* egil/cuddle-tests: stdlib: Increase timetrap for rand_SUITE common_test: Increase timetrap for cth_hooks_SUITE compiler: Increase timetrap timeouts for lc_SUITE
2016-12-07Add option 'deterministic' for reproducible buildsBjörn Gustavsson
Add the option 'deterministic' to make it easier to achieve reproducible builds. This option omits the {options,...} and {source,...} tuples in M:module_info(compile), because those options may contain absolute paths. The author of ERL-310 suggested that only compiler options that may contain absolute paths (such as {i,...}) should be excluded. But I find it confusing to keep only some options. Alternatives considered: Always omitting this information. Since this information has been available for a long time, that would probably break some workflows. As an example that some people care about {source,...}, 2d785c07fbf9 made it possible to give a compiler option to set {source,...}. ERL-310
2016-12-07Merge branch 'maint'Dan Gudmundsson
* maint: Update copyright-year Conflicts: lib/dialyzer/src/dialyzer.hrl lib/dialyzer/src/dialyzer_options.erl lib/dialyzer/test/opaque_SUITE_data/src/recrec/dialyzer.hrl lib/dialyzer/test/opaque_SUITE_data/src/recrec/dialyzer_races.erl lib/hipe/icode/hipe_icode.erl lib/hipe/main/hipe.erl lib/hipe/main/hipe.hrl.src lib/hipe/main/hipe_main.erl
2016-12-07Update copyright-yearErlang/OTP
2016-12-02Merge branch 'egil/compiler/opt-maps-pattern-matching/OTP-14072'Björn-Egil Dahlberg
* egil/compiler/opt-maps-pattern-matching/OTP-14072: compiler: Add regression tests compiler: Optimize maps pattern matching compiler: Allow for unaligned match argument in value groups
2016-12-01compiler: Add regression testsBjörn-Egil Dahlberg
2016-11-28Merge branch 'egil/compiler/maps-warn-repeated-keys/OTP-14058'Björn-Egil Dahlberg
* egil/compiler/maps-warn-repeated-keys/OTP-14058: compiler: Test repeated map key warnings compiler: Warn for repeated identical map keys
2016-11-23compiler: Test repeated map key warningsBjörn-Egil Dahlberg
2016-11-23Merge branch 'maint'Björn Gustavsson
* maint: Update primary bootstrap document {yield/nb_yield}() limitation Suppress warnings from v3_kernel when inlining is turned on
2016-11-18compile_SUITE: Make sure that guards are optimizedBjörn Gustavsson
Guards should use the more efficient 'test' instructions, not 'bif' instructions. Add a test to make sure that the optimizations don't degrade. We do have to keep an exception list for functions where we can't replace all 'bif' calls with 'test' instructions. We try to keep that list a short as practically possible.
2016-11-18Add test using LFE-generated Core Erlang modulesBjörn Gustavsson
Ensure that correct (not necessarily optimal) code is generated for Core Erlang code not originating from v3_core.
2016-11-18Remove beam_boolBjörn Gustavsson
The guard optimizations in v3_kernel has removed the need for beam_bool.
2016-11-18v3_kernel: Generate optimized code for guardsBjörn Gustavsson
The compiler produces poor code for complex guard expressions with andalso/orelse. Here is an example from the filename module: -define(IS_DRIVELETTER(Letter),(((Letter >= $A) andalso (Letter =< $Z)) orelse ((Letter >= $a) andalso (Letter =< $z)))). skip_prefix(Name, false) -> Name; skip_prefix([L, DrvSep|Name], DrvSep) when ?IS_DRIVELETTER(L) -> Name; skip_prefix(Name, _) -> Name. beam_bool fails to simplify the code for the guard, leaving several 'bif' instructions: {function, skip_prefix, 2, 49}. {label,48}. {line,[{location,"filename.erl",187}]}. {func_info,{atom,filename},{atom,skip_prefix},2}. {label,49}. {test,is_ne_exact,{f,52},[{x,1},{atom,false}]}. {test,is_nonempty_list,{f,52},[{x,0}]}. {get_list,{x,0},{x,2},{x,3}}. {test,is_nonempty_list,{f,52},[{x,3}]}. {get_list,{x,3},{x,4},{x,5}}. {bif,'=:=',{f,52},[{x,1},{x,4}],{x,6}}. {test,is_ge,{f,50},[{x,2},{integer,65}]}. {bif,'=<',{f,52},[{x,2},{integer,90}],{x,7}}. {test,is_eq_exact,{f,51},[{x,7},{atom,false}]}. {test,is_ge,{f,50},[{x,2},{integer,97}]}. {bif,'=<',{f,52},[{x,2},{integer,122}],{x,7}}. {jump,{f,51}}. {label,50}. {move,{atom,false},{x,7}}. {label,51}. {bif,'=:=',{f,52},[{x,7},{atom,true}],{x,7}}. {test,is_eq_exact,{f,52},[{x,6},{atom,true}]}. {test,is_eq_exact,{f,52},[{x,7},{atom,true}]}. {move,{x,5},{x,0}}. return. {label,52}. return. We can add optimizations of guard tests to v3_kernel to achive a better result: {function, skip_prefix, 2, 49}. {label,48}. {line,[{location,"filename.erl",187}]}. {func_info,{atom,filename},{atom,skip_prefix},2}. {label,49}. {test,is_ne_exact,{f,51},[{x,1},{atom,false}]}. {test,is_nonempty_list,{f,51},[{x,0}]}. {get_list,{x,0},{x,2},{x,3}}. {test,is_nonempty_list,{f,51},[{x,3}]}. {get_list,{x,3},{x,4},{x,5}}. {test,is_eq_exact,{f,51},[{x,1},{x,4}]}. {test,is_ge,{f,51},[{x,2},{integer,65}]}. {test,is_lt,{f,50},[{integer,90},{x,2}]}. {test,is_ge,{f,51},[{x,2},{integer,97}]}. {test,is_ge,{f,51},[{integer,122},{x,2}]}. {label,50}. {move,{x,5},{x,0}}. return. {label,51}. return. Looking at the STDLIB application, there were 112 lines of BIF calls in guards that beam_bool failed to convert to test instructions. This commit eliminates all those BIF calls. Here is how I counted the instructions: $ PATH=$ERL_TOP/bin:$PATH erlc -I ../include -I ../../kernel/include -S *.erl $ grep "bif,'[=<>]" *.S | grep -v f,0 dets.S: {bif,'=:=',{f,547},[{x,4},{atom,read_write}],{x,4}}. dets.S: {bif,'=:=',{f,547},[{x,5},{atom,saved}],{x,5}}. dets.S: {bif,'=:=',{f,589},[{x,5},{atom,read}],{x,5}}. . . . $ grep "bif,'[=<>]" *.S | grep -v f,0 | wc 112 224 6765 $
2016-11-18Suppress warnings from v3_kernel when inlining is turned onBjörn Gustavsson
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
2016-11-13record_SUITE: Strengthen test of record access in guardsBjörn Gustavsson
2016-11-11guard_SUITE: Add more test of guardsBjörn Gustavsson
2016-11-11compile_SUITE: Smoke test and cover more of v3_kernel_ppBjörn Gustavsson
2016-11-11compiler: Increase timetrap timeouts for lc_SUITEBjörn-Egil Dahlberg
* valgrind needs a lot of time
2016-11-03Merge branch 'gandrade/fmod/PR-1216/OTP-14000'Björn Gustavsson
* gandrade/fmod/PR-1216/OTP-14000: Add test cases for math:fmod/2 BIF Support math:fmod/2 BIF on compiler Add math:fmod/2 BIF
2016-11-02Add test cases for math:fmod/2 BIFGuilherme Andrade
2016-10-28sys_core_fold: Eliminate complaint from core_lintBjörn Gustavsson
2016-10-28Merge branch 'maint'Björn Gustavsson
* maint: Don't copy funs into guards
2016-10-27Don't copy funs into guardsBjörn Gustavsson
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.
2016-10-07Merge branch 'maint'Björn Gustavsson
* maint: beam_bsm: Eliminate unsafe optimization
2016-10-06beam_bsm: Eliminate unsafe optimizationBjörn Gustavsson
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
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-09-21bs_match_SUITE: Add a test case for beam_utilsBjörn Gustavsson
During development, a bug in beam_utils caused a compiler failure in xmerl. If the bug reappears, make sure that we catch it when compiling the compiler test suite.
2016-09-21bif_SUITE: Cover the remaining uncovered linesBjörn Gustavsson
2016-09-14Merge branch 'maint'Björn Gustavsson
* maint: beam_validator: Handle unreachable instructions Turn off parallel make for start scripts Makefile
2016-09-13beam_validator: Handle unreachable instructionsBjörn Gustavsson
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.
2016-09-07Merge branch 'maint'Björn Gustavsson
* maint: [snmp] Correct bug when path to mib contains UTF-8 characters [ic] Fix but when UTF-8 character in path to idl spec sys_core_fold: Don't move a fun into a guard
2016-09-05sys_core_fold: Don't move a fun into a guardBjörn Gustavsson
Moving a fun into a guard may cause code that is not accepted by beam_validator.
2016-09-05Merge branch 'bjorn/floor-ceiling/OTP-13692'Björn Gustavsson
* bjorn/floor-ceiling/OTP-13692: Add math:floor/1 and math:ceil/1 Implement the new ceil/1 and floor/1 guard BIFs
2016-09-05Add math:floor/1 and math:ceil/1Björn Gustavsson
Add math:floor/1 and math:ceil/1 to avoid unnecessary conversions in floating point expressions. That is, instead of having to write float(floor(X)) as part of a floating point expressions, we can write simply math:floor(X).
2016-09-05Implement the new ceil/1 and floor/1 guard BIFsBjörn Gustavsson
Implement as ceil/1 and floor/1 as new guard BIFs (essentially part of Erlang language). They are guard BIFs because trunc/1 is a guard BIF. It would be strange to have trunc/1 as a part of the language, but not ceil/1 and floor/1.
2016-09-02Fix overridden BIFsBjörn Gustavsson
The filters in a list comprehension can be guard expressions or an ordinary expressions. If a guard expression is used as a filter, an exception will basically mean the same as 'false': t() -> L = [{some_tag,42},an_atom], [X || X <- L, element(1, X) =:= some_tag] %% Returns [{some_tag,42}] On the other hand, if an ordinary expression is used as a filter, there will be an exception: my_element(N, T) -> element(N, T). t() -> L = [{some_tag,42},an_atom], [X || X <- L, my_element(1, X) =:= some_tag] %% Causes a 'badarg' exception when element(1, an_atom) is evaluated It has been allowed for several releases to override a BIF with a local function. Thus, if we define a function called element/2, it will be called instead of the BIF element/2 within the module. We must use the "erlang:" prefix to call the BIF. Therefore, the following code is expected to work the same way as in our second example above: -compile({no_auto_import,[element/2]}). element(N, T) -> erlang:element(N, T). t() -> L = [{some_tag,42},an_atom], [X || X <- L, element(1, X) =:= some_tag]. %% Causes a 'badarg' exception when element(1, an_atom) is evaluated But the compiler refuses to compile the code with the following diagnostic: call to local/imported function element/2 is illegal in guard
2016-09-01compiler: Eliminate use of sys_pre_expandBjörn Gustavsson
sys_pre_expand previously did a lot more work, for example, translating records and funs, but now is merely a grab bag of small transformations. Move those transformations to v3_core.
2016-08-19Strengthen test case added in 8b83bc0bBjörn Gustavsson
Don't only test the case that failed; test it exhaustively.
2016-08-12Merge branch 'maint'Björn Gustavsson
* maint: asn1_test_lib: Compile ASN.1 modules in parallel Support 'make -j' when compiling ASN.1 modules [ERL-209] Fix ambiguous_catch_try_state inconsistency error
2016-08-11[ERL-209] Fix ambiguous_catch_try_state inconsistency errorBjörn Gustavsson
It is not safe to share code between 'catch' blocks.
2016-08-10Merge branch 'josevalim/large-binary-strings/PR-1131/OTP-13794'Björn Gustavsson
* josevalim/large-binary-strings/PR-1131/OTP-13794: Move expansion of strings in binaries to v3_core
2016-08-05Merge branch 'maint'Björn Gustavsson
* maint: Update primary bootstrap beam_block: Fix potentially unsafe optimization in move_allocates/1
2016-08-05beam_block: Fix potentially unsafe optimization in move_allocates/1Björn Gustavsson
beam_block has an optimization that only is safe when it is applied immediately after code generation. That is pointed out in a comment: NOTE: Moving allocation instructions is only safe because it is done immediately after code generation so that we KNOW that if {x,X} is initialized, all x registers with lower numbers are also initialized. That assumption may not be true after other optimizations, such as the beam_utils:live_opt/1 optimization. The new beam_reorder pass added in OTP 19 runs before beam_block. Therefore, the optimization is potentially unsafe. The optimization is also unsafe if compilation is started from assembly code in a .S file. Rewrite the optimization to make it safe. See the newly added comment for details. ERL-202
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-15 09:52:37 +0000