[Tarantool-patches] [PATCH luajit 4/5] Fix pow() optimization inconsistencies.
Sergey Bronnikov
sergeyb at tarantool.org
Fri Aug 18 15:45:57 MSK 2023
Hi, Sergey!
thanks for the patch! LGTM with two minor comments inline.
On 8/15/23 12:36, Sergey Kaplun wrote:
> From: Mike Pall <mike>
>
> (cherry-picked from commit 9512d5c1aced61e13e7be2d3208ec7ae3516b458)
>
> This patch fixes different misbehaviour between JIT-compiled code and
misbehaviour -> misbehaviours
> the interpreter for power operator with the following ways:
> * Drop folding optimizations for base ^ 0.5 => sqrt(base), as far as
> pow(base, 0.5) isn't interchangeable and depends on the <math.h>
> implementation.
> * Drop folding optimizations for 2 ^ int_pow => ldexp(1.0, int_pow), to
> avoid dependcy on the <math.h> implementation.
dependcy -> dependency
> * Now `asm_pow()` always assemble a call to the `lj_vm_powi()` function,
> that is general now for all CPU architectures. Using this internal
> function instead of toolchain-provided `pow()` guarantees consistency
> between interpreter and JIT results. Also, it drops custom
> implementation for the `vm_powi_sse()` on x86_64.
> * `math_extern2` macro in the VM may take the second argument, that is
> used as the target function to call. The first argument is still the
> name for `func_nnsse` macro.
> * Narrowing for power operation avoids range guard for non-constant base
> IR. This leads to invalid result if value on trace is out of range.
> Now it is done unconditionally.
>
> Be aware, that [220/502] lib/string/format/num.lua test [1] from
> LuaJIT-test suite fails after this commit.
>
> [1]: https://www.exploringbinary.com/incorrect-floating-point-to-decimal-conversions/
>
> Sergey Kaplun:
> * added the description and the test for the problem
<snipped>
More information about the Tarantool-patches
mailing list