Implemented floating-point multiplication.

Removed the complicated handling of lj_vm_ffi_call (it was a variable
size frame) and now backtrace works all over (e.g:)

 #0  0x00003fffb7d4875c in __libc_send (fd=32, buf=0x3fffb09a0028, len=8192, flags=0) at ../sysdeps/unix/sysv/linux/send.c:31
 #1  0x00003fffb7bea214 in socket_send (ps=0x3fffb7bc7778, data=0x3fffb09a0028 'A' <repeats 200 times>..., count=8192, sent=0x3fffffffee60, tm=0x3fffb7bc97d8) at usocket.c:205
 #2  0x00003fffb7be4ef8 in sendraw (buf=0x3fffb7bc77a0, data=0x3fffb09a0028 'A' <repeats 200 times>..., count=52428800, sent=0x3fffffffeee8) at buffer.c:176
 #3  0x00003fffb7be4960 in buffer_meth_send (L=0x3fffb7f6d280, buf=0x3fffb7bc77a0) at buffer.c:87
 LuaJIT#4  0x00003fffb7bec3f4 in meth_send (L=0x3fffb7f6d280) at tcp.c:130
 LuaJIT#5  0x0000000010042d44 in lj_BC_FUNCC ()
 LuaJIT#6  0x0000000010043f24 in lj_ff_coroutine_resume ()
 LuaJIT#7  0x000000001001d7d4 in lua_pcall (L=0x3fffb7f60378, nargs=0, nresults=-1, errfunc=2) at lj_api.c:1129
 LuaJIT#8  0x00000000100045e8 in docall (L=0x3fffb7f60378, narg=0, clear=0) at luajit.c:121
 LuaJIT#9  0x00000000100053ec in handle_script (L=0x3fffb7f60378, argx=0x3ffffffffa40) at luajit.c:291
 LuaJIT#10 0x0000000010006600 in pmain (L=0x3fffb7f60378) at luajit.c:551
 LuaJIT#11 0x0000000010042d44 in lj_BC_FUNCC ()
 LuaJIT#12 0x000000001001da40 in lua_cpcall (L=0x3fffb7f60378, func=0x10006334 <pmain>, ud=0x0) at lj_api.c:1153
 LuaJIT#13 0x00000000100067a4 in main (argc=2, argv=0x3ffffffffa38) at luajit.c:580

Repo sync

Thanks to Sergey Kaplun and Peter Cawley.

(cherry-picked from commit 1761fd2)

Assume we have the parent trace with the following IRs:

| 0001 }  tab TNEW   #0    #0
| 0002 }  p32 NEWREF 0001  "key"
| 0003 }  fal HSTORE 0002  false
| ....        SNAP   LuaJIT#1   [ ---- ---- 0001 ---- ]
| 0004 >  num SLOAD  LuaJIT#1    T
| ....        SNAP   LuaJIT#2   [ ---- ---- 0001 ]
| 0005 >  num EQ     0004  0004
| 0006 }  tru HSTORE 0002  true
| ....        SNAP   LuaJIT#3   [ ---- ---- 0001 true ]

The side trace for the third snapshot emits the following IRs:

| 0001    tab TNEW   #0    #0
| 0002    p32 NEWREF 0001  "key"
| 0003    fal HSTORE 0002  false
| 0004    p32 NEWREF 0001  "key"
| 0005    tru HSTORE 0004  true

As we can see, `NEWREF` is emitted twice. This is a violation of its
semantics, so the second store isn't noticeable.

This patch prevents the second emitting of IR NEWREF by checking the last
one emitted NEWREF IR. There is no need to check NEWREFs beyond since
it guarantees the snapshot is taken after it, because it may cause table
rehashing, so all prior results are invalidated.

Sergey Kaplun:
* added the description and the test for the problem

Resolves tarantool/tarantool#7937
Part of tarantool/tarantool#9145

Reviewed-by: Maxim Kokryashkin <[email protected]>
Reviewed-by: Sergey Bronnikov <[email protected]>
Signed-off-by: Igor Munkin <[email protected]>

Thanks to Sergey Kaplun and Peter Cawley.

(cherry-picked from commit 1761fd2)

Assume we have the parent trace with the following IRs:

| 0001 }  tab TNEW   #0    #0
| 0002 }  p32 NEWREF 0001  "key"
| 0003 }  fal HSTORE 0002  false
| ....        SNAP   LuaJIT#1   [ ---- ---- 0001 ---- ]
| 0004 >  num SLOAD  LuaJIT#1    T
| ....        SNAP   LuaJIT#2   [ ---- ---- 0001 ]
| 0005 >  num EQ     0004  0004
| 0006 }  tru HSTORE 0002  true
| ....        SNAP   LuaJIT#3   [ ---- ---- 0001 true ]

The side trace for the third snapshot emits the following IRs:

| 0001    tab TNEW   #0    #0
| 0002    p32 NEWREF 0001  "key"
| 0003    fal HSTORE 0002  false
| 0004    p32 NEWREF 0001  "key"
| 0005    tru HSTORE 0004  true

As we can see, `NEWREF` is emitted twice. This is a violation of its
semantics, so the second store isn't noticeable.

This patch prevents the second emitting of IR NEWREF by checking the last
one emitted NEWREF IR. There is no need to check NEWREFs beyond since
it guarantees the snapshot is taken after it, because it may cause table
rehashing, so all prior results are invalidated.

Sergey Kaplun:
* added the description and the test for the problem

Resolves tarantool/tarantool#7937
Part of tarantool/tarantool#9145

Reviewed-by: Maxim Kokryashkin <[email protected]>
Reviewed-by: Sergey Bronnikov <[email protected]>
Signed-off-by: Igor Munkin <[email protected]>
(cherry picked from commit 005e8ce)

Thanks to Sergey Kaplun and Peter Cawley.

(cherry-picked from commit 1761fd2)

Assume we have the parent trace with the following IRs:

| 0001 }  tab TNEW   #0    #0
| 0002 }  p32 NEWREF 0001  "key"
| 0003 }  fal HSTORE 0002  false
| ....        SNAP   LuaJIT#1   [ ---- ---- 0001 ---- ]
| 0004 >  num SLOAD  LuaJIT#1    T
| ....        SNAP   LuaJIT#2   [ ---- ---- 0001 ]
| 0005 >  num EQ     0004  0004
| 0006 }  tru HSTORE 0002  true
| ....        SNAP   LuaJIT#3   [ ---- ---- 0001 true ]

The side trace for the third snapshot emits the following IRs:

| 0001    tab TNEW   #0    #0
| 0002    p32 NEWREF 0001  "key"
| 0003    fal HSTORE 0002  false
| 0004    p32 NEWREF 0001  "key"
| 0005    tru HSTORE 0004  true

As we can see, `NEWREF` is emitted twice. This is a violation of its
semantics, so the second store isn't noticeable.

This patch prevents the second emitting of IR NEWREF by checking the last
one emitted NEWREF IR. There is no need to check NEWREFs beyond since
it guarantees the snapshot is taken after it, because it may cause table
rehashing, so all prior results are invalidated.

Sergey Kaplun:
* added the description and the test for the problem

Resolves tarantool/tarantool#7937
Part of tarantool/tarantool#9145

Reviewed-by: Maxim Kokryashkin <[email protected]>
Reviewed-by: Sergey Bronnikov <[email protected]>
Signed-off-by: Igor Munkin <[email protected]>
(cherry picked from commit 005e8ce)