| Age | Commit message (Collapse) | Author |
|---|
|
Moving away this optimization makes beam_block do one thing
and one thing only -- creating blocks.
|
|
The only caller of bif_to_test/3 is beam_ssa_codegen.
|
|
Disallow a literal map source for get_map_elements. There is currently
runtime support for get_map with a literal map source, but by
forbidding it in OTP 22, the runtime support could be removed in a
future release (perhaps OTP 24).
Also verify that the source arguments for get_list, get_hd, get_tl,
and get_tuple_element are not literals. Literals are not supported for
those instructions in the runtime system; verifying it in
beam_validator is a convenience so that this kind of bug will
be detected already during compilation.
|
|
The source map for `get_map_element` is not supposed to be a literal,
and the sanitization code is supposed to ensure that.
The sanitization incorrectly translated this code:
Map = get_tuple_element literal {ok,#{key=>value}}, literal 1
Var = get_map_element Map, literal {a,key}
To this code:
Var = get_map_element literal #{key=>value}, literal {a,key}
Make sure to substitute the arguments for `get_map_element` before
looking for a literal source map.
|
|
|
|
Using maps and cerl_sets instead of dict and sets will slightly
speed up the beam_clean pass for modules with many functions
and/or calls to local functions.
|
|
It is not necessary to combine get_hd and get_tl instruction to
a get_list instruction. It will be done in beam_z.
After this change, beam_flatten does nothing more than eliminating
the blocks.
|
|
Continuing the simplification of beam_flatten, move the optimization
that eliminates a test_heap instruction following a binary construction
by incorporating the allocation of the heap space into the bs_init*
instruction itself.
This change does not change the generated code in any way.
Also remove beam_utils:combine_heap_needs/2, because beam_flatten
was the last user of it.
|
|
The purpose of beam_flatten is to eliminate the blocks created by
beam_block, but it also does a few optimizations because at the
time the optimizations were added, beam_flatten was the most
convenient place.
Move the optimization that places `{move,Something,{x,0}}` before
`call` instructions from beam_flatten to beam_ssa_codegen.
This change will very slightly improve compilation times, and it
will also apply the optimization in more places. In particular,
a `{move,Literal,{x,0}}` would never be moved passed a `trim`
instruction before this change. Now it will.
|
|
Signed-off-by: Peter Lemenkov <[email protected]>
|
|
Signed-off-by: Peter Lemenkov <[email protected]>
|
|
jhogberg/john/compiler/validator-aliased-type-fixes/ERL-735
beam_validator: Use set_aliased_type in more operations
|
|
It is already allowed in match-specs.
|
|
The following code broke because aliases weren't tracked for hd/1:
bug(Bool) ->
Bug = remote:call(),
if
Bool -> %% Branch of some kind.
_ = hd(Bug),
remote:call(),
hd(Bug)
end.
Related to 1f221b27f1336e747f7409692f260055dd3ddf79
|
|
This is needed for testcases to run correctly.
|
|
fix for ppc64le / add travis test for ppc64le
OTP-15313
|
|
|
|
to reduce test times
|
|
Avoid repeating same tests for [] and [set].
Test case 'default' verifies 'set' to be the default type.
|
|
|
|
|
|
|
|
|
|
get_anno/3: as get_anno but with a default value
definitions/1-2: returns a map of variable definitions (#b_set{})
uses/1-2: returns a map of all uses of a given variable
mapfold_blocks_rpo/4: mapfolds over blocks
|
|
The upcoming beam_ssa_bsm pass makes this redundant.
|
|
Clean up variable-related cruft in new SSA passes
|
|
by populating the table with the help of a random number generator
creating series of unique integers.
|
|
Add a more scalable ETS ordered_set implementation
|
|
* maint:
crypto: Fix accidental merge
|
|
Commit 8c47a7657d03777a03a6838c7ec937b6347d07f8 accidently
reverted the changes in lib/crypto/src/crypto.erl correctly
introduced in e8de0736005e91afd992e49f434e08c940eddfa0
This fix re-introduces the correct changes.
|
|
|
|
|
|
|
|
|
|
Now that variables are represented as #b_var{}, there's no longer
any risk of colliding with anything else.
|
|
We chose to refer to variables through their var_name() because we
anticipated the need to annotate them, but it turned out we didn't
really need that, and many things become a lot cleaner if the
entire #b_var{} is used to represent variables.
|
|
|
|
* ingela/ERL-622/fix:
ssl: Move link to correct process
|
|
The link should be between the connection process and the tls_sender
process. But the start of the tls_sender process needs to be done
by the process that also starts the connection process in order to
correctly create the opaque #ssl_socket{}.
|
|
OTP-14737
* raimo/stdlib/gen_statem-cleanup:
Improve user's guide on time-outs
Clean up and optimize code and doc
|
|
|
|
* raimo/receive-TOS-TCLASS/ERIERL-187/OTP-15145:
Elaborate the disclaimer for 'pktoptions'
Improve platform filter
Fix endianness bug for CMSG parsing
|
|
|
|
|
|
* maint:
crypto: Re-work the 'Description' section
crypto: Add warnings in RefMan and User's Guide for experimental RSA opts
|
|
Links and contents needs update.
|
|
Replace beam_dead with beam_ssa_dead
|
|
OTP-14461 - New 'rand' algorithm: Xoroshiro928** also for 'crypto'
Implement a new 'rand' algorithm named 'exro928ss' and a new 'crypto' plugin for 'rand' named 'crypto_aes'.
Both are based on Xoroshiro928** which is derived from Xoroshiro1024** modified to use 58-bit words for performance reasons in the Erlang VM. Xoroshiro1024** has got the Xoroshiro1024 generator and the StarStar scrambler from the 2018 paper "Scrambled Linear Pseudorandom Number Generators" by David Blackman and Sebastiano Vigna.
This generator and scrambler combination shows no systematic weaknesses in standard statistical tests as TestU01(BigCrush) and PractRand, unlike the previously used * and + scramblers in the 'rand' module that exhibit statistical weaknesses for the lowest bits.
The 'crypto' plugin uses AES-256 as scrambler and the Xoroshiro928 as generator, which gives the same very long period and jump functions as for Xoroshiro928**, but a cryptographically secure scrambler gives absolutely no detectable statistical weaknesses regardless of how the generated numbers are used.
The speed of 'exro928ss' is only about 30-50% slower than the default fast 'rand' algorithm, but the state is roughly the double and it produces about 8 times the garbage per iteration.
The speed of 'crypto_aes' is about half (amortized) that of the default fast 'rand' algorithm which is fast and thanks to doing encryption in batches caching the result. Hence the state is much larger.
|
|
|
|
* maint:
Updated OTP version
Update release notes
Update version numbers
Fix include-path regression caused by dd0a39c
|
