#530: Failure of atan2 in jit core - ref TT #38
--------------------+-------------------------------------------------------
Reporter: mikehh | Type: bug
Status: new | Priority: normal
Milestone: | Component: none
Version: trunk | Severity: medium
Keywords: | Lang:
Patch: | Platform: linux
--------------------+-------------------------------------------------------
Comment(by rg):
I've finally figured out the reason for these failures:[[BR]]
Parrot is mapping some N registers to x87 floating point registers. Before
calling a non-jitted function, the registers are written back to memory
(the N registers), however, they are not removed from the x87 registers.
The problem with that is, that x87 treats those registers as a stack and
produces a failure when it hits a register that is in use. What's worse is
that Intel's documentation does not have a big warning that even if you're
ignoring the stack overflow error, you're not getting the result you
wanted, but a NaN instead. The thing is, the OS math libraries in question
hit the registers used by parrot's jit, suddenly have junk values in their
registers and the tests fail. (On FreeBSD, the pow function even uses the
whole 8 registers, i.e. there may be *nothing* left behind in the
registers.)
Now I've tried to change the function that saves the registers to also
clear them, but I've hit a snag in the design of the jit there. Basically,
the registers are also saved before a branch (or jump) statement, however
if the branch is conditional and depends on a value from a number
register, it assumes it's still there, i.e. all hell breaks loose after
changing that ;)
As a result, the only solution I can offer so far is to not map any float
registers. I'm attaching a patch that does just that and fixes a couple of
resulting or related bugs aswell. It passes the same tests as without the
patch for me on Ubuntu 9.04 beta and FreeBSD 7.1 (i386 obviously) plus the
previously failed or todo-ed ones from trans.t.
Unfortunately, the jit code is not easy to work with, either. It has
obviously evolved and some of the obsolete parts seem to be still in
there. Therefor, I'm not sure how to proceed. Obviously I'd like to see
the patch committed, so we are more correct. On the other hand, not
mapping any float registers is of course a bit of a performance hit (not
much since only true jitted ops can benefit from the mapped registers and
there really aren't that many of those), still it's not the right thing to
do. My problem is, I don't have the time to get it right. So are we going
to open yet another ticket to describe what's really required? Ignore jit?
Get a better jit from gsoc? Just leave this ticket open for someone to fix
things properly?
Please advise.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/530#comment:5>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
