Age | Commit message (Collapse) | Author |
|
|
|
|
|
Profiling shows that the excution time for checkerror_1/2 could
be be near the top even for modules without any floating point
operations.
It turns out that the complexity of simplify_float_1/4 is quadratic.
checkerror/1 is called with the growing accumulator for each
iteration. checkerror/1 will traverse the entire accumulated list
*unless* some floating point operations are used.
We can avoid this situation if we only call checkerror/1 when there
are live floating point registers. We can also avoid calling flush/3
if there are no live floating point registers.
|
|
When calculating the number of live registers for allocation
instruction, it is not always safe to start with the number of live
registers at the start of the block. We will need to use the register
map to know whether there are any holes (dead registers) that are not
subsequently filled.
If the allocation instruction already has a number of live registers
calculated, there is nothing to be gained by raising it.
|
|
As a preparation for fixing a bug, introduce a complete register
map in the '%live' annotations.
|
|
|
|
|
|
|
|
The compiler shouldn't crash when fed an already-optimised BEAM assembly file.
|
|
files as delimiters.
While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.
|
|
|
|
In code such as:
X / 2
the following code would be output from beam_type for the division:
{fconv,{x,0},{fr,0}}.
{fconv,{integer,2},{fr,1}}.
fclearerror.
{bif,fdiv,{f,0},[{fr,0},{fr,1}],{fr,0}}.
That is, the integer 2 would be converted to the float 2.0 at
run-time by "{fconv,{integer,2},{fr,1}}". Make sure that we do
the conversion at compile time.
Noticed-by: Richard O'Keefe
|
|
|
|
|
|
|
|
Allow line/1 instructions to be part of a sequence of floating point
instructions to avoid outputting fclearerror / fcheckerror around
every floating point instruction.
|
|
|
|
The clause does not server any useful purpose, since it does the
same as the default clause at the end.
|
|
The following instruction sequence:
fmove {fr,Fr} {x,TempXreg}
move {x,TempXreg} {y,Dest}
is rewritten to:
fmove {fr,Fr} {y,Dest}
(Provided that {x,TempXreg} is killed by the instructions following
the sequence.)
Generalize the optimization to also handle:
fmove {fr,Fr} {x,TempXreg}
move {x,TempXreg} {_,Dest}
That is, the destination register can be either an X or Y register.
|
|
* bg/compiler-remove-r11-support:
compiler: Don't support the no_binaries option
erts: Don't support the put_string/3 instruction
compiler: Don't support the no_constant_pool option
compiler: Don't support the r11 option
test_server: Don't support communication with R11 nodes
binary_SUITE: Don't test bit-level binary roundtrips with R11 nodes
erts: Test compatibility of funs with R12 instead of R11
OTP-8531 bg/compiler-remove-r11-support
|
|
The no_constant_pool option was implied by the r11 option. It turns
off the usage of the constant (literal) pool, so that BEAM
instructions that use constants can be loaded in an R11 system.
Since the r11 option has been removed, there is no need to
retain the no_constant_pool option.
|
|
|