| Age | Commit message (Collapse) | Author |
|---|
|
Fetch the head and tail parts to temporary variables before
writing them to their destinations. That should allow the CPU to
perform the moves in parallel, which might improve performance.
|
|
The combination is_non_empty_list followed by get_list is extremly
common (but not in estone_SUITE, which is why it has not been noticed
before). Therefore it is worthwile to introduce a combined
instruction.
|
|
|
|
It is currently only possible to pack up to 4 operands. However,
the move_window4 instrucion has 5 operands and move_window5 and
move3 instrucations have 6 operands.
Teach beam_makeops to pack instructions with 5 or 6 operands.
Also rewrite the move_window instructions in beam_emu.c to macros
to allow their operands to get packed.
|
|
Since 'd' operands can only either an X register or an Y register,
we only need a single bit to distinguish them. Furthermore, we can
pre-multiply the register number with the word size to speed up
address calculation.
|
|
Sequences of three move instructionst that effectively swap the
contents of two registers are fairly common. We can replace them
with a swap_temp/3 instruction. The third operand is the temporary
register to be used for swapping, since the temporary register
may actually be used.
If swap_temp/3 instruction is followed by a call, the temporary
register will often (but not always) be killed by the call. If
it is killed, we can replace the swap_temp/3 instruction with a
slightly cheaper swap/2 instruction.
|
|
Currently, move2/2 does the two moves sequentially to ensure
that the instruction will always work correctly.
We can do better than that. If the two move instructions have
any registers in common, we can introduce simpler and slightly
more efficient instructions to handle those cases:
move_shift/3
move_dup/3
For the remaining cases when the the move instructions
have no common registers, the move2/4 instruction can perform
the moves in parallel which is probably slightly more efficient.
For clarity's sake, we will remain the instruction to move2_par/4.
|
|
|
|
The 'cmd' variable that were shared by several hipe_mode_switch
instructions would cause clang to produce sub-optimal code,
probably because it considered the instructions as part of of
loop that needed to be optimized.
What would was that 'cmd' would be assigned to the ESI register
(lower 32 bits of the RSI register). It would use ESI for other
purposes in instructions, but at the end of every instruction
it would set ESI to 1 just in case the next instruction happened
to be hipe_trap_return. This can be seen clearly if this commit
is omitted and the define HIPE_MODE_SWITCH_CMD_RETURN in
hipe/hipe_mode_switch.h is changed from 1 to some other number
such as 42. You will see that 42 is assigned to ESI at the end
of every instruction.
Eliminate this problem by elimininating the shared 'cmd' variable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The i_fetch instruction fetches two operands and places them
in the tmp_arg1 and tmp_arg2 variables. The next instruction
(such as i_plus) does not have to handle different types of
operands, but can get get them simply from the tmp_arg*
variables. Thus, i_fetch was introduced as a way to temper
a potentail combinatorial explosion.
Unfortunately, clang will generate terrible code because of
the tmp_arg1 and tmp_arg2 variables being live across multiple
instructions. Note that Clang has no way to predict the control
flow from one instruction to another. Clang must assume that
any instruction can jump to any other instruction. Somehow GCC
manages to cope with this situation much better.
Therefore, to improve the quality of the code generated by clang, we
must eliminate all uses of the tmp_arg1 and tmp_arg2 variables. This
commit eliminates the use of i_fetch in combination with the
arithmetic and logical instructions.
While we are touching the code for the bsr and bsl instructions,
also move the tmp_big[] array from top scope of process main into
the block that encloses the bsr and bsl instructions.
|
|
The 'r' type is now mandatory. That means in order to handle
both of the following instructions:
move x(0) y(7)
move x(1) y(7)
we would need to define two specific operations in ops.tab:
move r y
move x y
We want to make 'r' operands optional. That is, if we have
only this specific instruction:
move x y
it will match both of the following instructions:
move x(0) y(7)
move x(1) y(7)
Make 'r' optional allows us to save code space when we don't
want to make handling of x(0) a special case, but we can still
use 'r' to optimize commonly used instructions.
|
|
Consider the try_case_end instruction:
try_case_end s
The 's' operand type means that the operand can either be a
literal of one of the types atom, integer, or empty list, or
a register. That worked well before R12. In R12 additional
types of literals where introduced. Because of way the
overloading was done, an 's' operand cannot handle the
new types of literals. Therefore, code such as the following
is necessary in ops.tab to avoid giving an 's' operand a
literal:
try_case_end Literal=q => move Literal x | try_case_end x
While this work, it is error-prone in that it is easy to
forget to add that kind of rule. It would also be complicated
in case we wanted to introduce a new kind of addition operator
such as:
i_plus jssd
Since there are two 's' operands, two scratch registers and
two 'move' instructions would be needed.
Therefore, we'll need to find a smarter way to find tag
register operands. We will overload the pid and port tags
for X and Y register, respectively. That works because pids
and port are immediate values (fit in one word), and there
are no literals for pids and ports.
|
|
|
|
As part of improving code generation for clang, we want to
eliminate the special variable that stores the content of X
register zero most of the time. In a future, that will allow us
to eliminate the special case of handling r(0) for most
instructions, thus reducing the code size and allow other
simplifcations.
Therefore, in this commit, eliminate the variable that is used
to store r(0) and make r(0) as synonym for x(0). I have chosen
to keep the r(0) define to keep the size of the diff managable.
|
|
|
|
|
|
* Removed COMPRESS_POINTER and EXPAND_POINTER
|
|
|
|
|
|
by adding a dynamic heap factory.
"binary_to_term" is now a hybrid solution with both
a call to decoded_size() to calculate needed heap space
AND possible dynamic allocation of more heap space
if needed for big maps.
The heap size returned from decoded_size() is guaranteed
to be sufficient for all term heap data except for hashmap
nodes. All hashmap nodes are created at the end of dec_term()
by invoking the heap factory interface that may allocate more
heap space on process heap or in fragments.
With this commit it is no longer guaranteed that a message
is confined to only one heap fragment.
|
|
Previously, the emulator would generate a whole string
with values and call the error_logger passing "~s~n".
This commit changes it to a format string containing ~p
with the respective values as arguments.
|
|
* rickard/timer-optimization/OTP-12650:
Optimized timer implementation
Reusable red-black tree implementation
Conflicts:
erts/emulator/beam/erl_bif_timer.c
|
|
|
|
* egil/opt-instructions/OTP-12690:
erts: Specialize minus and plus instruction
erts: Add move2 specialization for common move patterns
erts: Specialize rem instruction for common case
erts: Specialize band instruction for common case
erts: Batch loads and stores for move_window
erts: Fix loader increment from minus instruction
erts: Add move window instruction
erts: Add instruction move3 for xy and xx
erts: Specialize compare instructions
kernel: Add instruction_count helper to erts_debug
|
|
Seen on SSL application where substraction with x registers were prevalent:
* i_minus specialization on x registers
* i_plus specialization on x registers
|
|
* i_rem specialization on x registers
|
|
* i_band specialization on x registers and constants
|
|
May lessen load/store latency.
|
|
Move an entire region of x registers to the stack.
This reduces the dispatch pressure of move instructions.
Also introduce a move2 specialization for some common move patterns:
move r y | move x y -> move2 : As above, moving regions to the stack
move x r | move x y -> move2 : A seemingly common pattern
|
|
|
|
* i_is_lt for r, x registers and constants
* i_is_ge for x registers and constants
* i_is_exact_eq for r and x registers
|
|
* sverk/pr632/prevent-illegal-nif-terms/OTP-12655:
erts: Reject non-finite float terms in erl_drv_output_term
erts: Remove old docs about experimental NIF versions.
erts: Add enif_has_pending_exception
erts: Clearify erl_nif documentation about badarg exception
erts: Fix compile warning in enif_make_double
erts: Fix divide by zero compile error in nif_SUITE.c
erts: Fix isfinite for windows
Ensure NIF term creation disallows illegal values
|
|
* Assertion is only removed because we are in icount mode.
|
|
* bjorn/maps:
Document the new {badmap,Term} and {badkey,Key} exceptions
Raise more descriptive error messages for failed map operations
erl_term.h: Add is_not_map() macro
Tigthen code for the i_get_map_elements/3 instruction
Pre-compute hash values for the general get_map_elements instruction
Teach the loader to pre-compute the hash value for single-key lookups
Optimize use of i_get_map_element/4
beam_emu: Slightly optimize update_map_{assoc,exact}
v3_codegen: Don't sort map keys in map creation/update
beam_validator: No longer require strict literal term order
Sort maps keys in the loader
De-optimize the has_map_fields instructions
erts/map_SUITE.erl: Add a test case that tests has_map_fields
Fully evaluate is_map/1 for literals at load-time
map_SUITE: Add tests of is_map/1 with literal maps
Run a clone of map_SUITE without optimizations
Remove the fail label operand of the new_map instruction
Correct transformation of put_map_assoc to new_map
Remove support for put_map_exact without a source map
|
|
According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:
<<>>#{a=>42}
That was not implemented in the OTP 17.
José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:
http://erlang.org/pipermail/erlang-questions/2015-February/083588.html
This commit implement better errors from map operations similar
to his suggestion.
When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:
{badmap,Term}
This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.
When a map operation requires a key that is not present in a map,
the following exception will be raised:
{badkey,Key}
José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.
For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.
If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.
|
|
|
|
|
|
See the previous commit for justification and use cases.
|
|
Let the loader pre-compute the hash value when a single, literal key
is matched as in:
#{<<"some_key">>:=V} = Map
In my measurements, this optimization resulted in a 30 percent
speedup for short binary keys.
Unfortunately, this optimizization makes no difference for small
maps with less than 32 keys, since the hash value is not used.
Still, there are the following use cases:
* A map used instead of a record with more than 32 entries. I have
seen some applications with huge records.
* Lookup in JSON dictionaries represented as maps.
The hash value will only be used when the map is a hash map
(currently, that means at least 32 entries).
|
|
In the update loop for big maps, the E variable is restored for
each turn of the loop. It only needs to be restored if a garbage
collection has been performed.
Also add a new test case that attempts to force several garbage
collections while updating a map, to help us find bugs with
incorrect restoration of the E variable after a garbage collection.
|
|
The has_map_fields instruction is infrequently used. Thus there
is no need to have the fastest possible implementation; it is
better to have an implementation that reduces the code size in
the already big process_main() function.
We can transform has_map_fields to a get_map_elements instruction,
targeting the same unused x[0] register for all keys. That
instruction will only be marginally slower than existing
implementation.
|
|
The new_map instruction cannot fail, and thus needs no fail label.
|
|
|
|
|
