Re: [Tarantool-patches] [PATCH luajit 4/5] Fix pow() optimization inconsistencies.

[Sergey Bronnikov via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

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>