We compile floating-point code but can't deal with it properly

[ltratt]

@Pavel-Durov noticed in ykjit/yklua#19 that yklua + mandelbrot.lua crash in odd ways. There are two causes. One is an out-of-memory that isn't relevant to this issue, but another is that the benchmark uses floating point, which a) we don't seem to handle b) we let through a trace. Pavel saw this in a backtrace:

[New Thread 0x7fffee334640 (LWP 15861)]
[Thread 0x7fffee334640 (LWP 15861) exited]
[New Thread 0x7fffee334640 (LWP 15880)]
[Thread 0x7fffee334640 (LWP 15880) exited]
[New Thread 0x7fffee334640 (LWP 15925)]
[Thread 0x7fffee334640 (LWP 15925) exited]
instrinsic is missing `yk.intrinsic.inlined` metadata:   %12 = call double @llvm.floor.f64(double %10), !dbg !9033[Inferior 1 (process 15581) exited with code 01]
(gdb) bt

At the very least we should add some sort of assert/panic at JIT time when we encounter FP code, so that we don't let the program stumble on to an inevitable, and confusing, death. Ideally we'd actually fix whatever stops us handling FP stuff (@vext01 suggested we don't deal with FP registers? maybe that's the only problem?).

@Pavel-Durov perhaps you could look into the "assert/panic" fix? I suspect the wider issue will take help from @ptersilie.

[Pavel-Durov]

"assert/panic" was added in 2a267f1
Should we close it? Or was it only partially addressed?

[ltratt]

I think that's one for @ptersilie .

[ptersilie]

I need to look into how stackmaps handle floats, since I believe deopt is what keeps this from working currently.

[vext01]

I assume it simply reports a FP register or a normal stack slot. But we certainly don't preserve/restore the FP registers over deopt.

[Pavel-Durov]

Related issues in yklua:
ykjit/yklua#37
ykjit/yklua#46
ykjit/yklua#47
ykjit/yklua#53
ykjit/yklua#56

[vext01]

@Pavel-Durov @ptersilie What's the status of this one? Did we fix floats, or did I imagine it?