463743 - Update x64 port for redux nanojit

Status: VERIFIED WONTFIX

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

Working on this now, my TODO list so far:
 - Split LIR_quad into LIR_quad and LIR_float
 - Add LIR_qcall
 - Get stack reservation to play nicely with STACK_GRANULARITY==8
 - Fix ensureRoom() calls

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: nanojit changes so far

No r? yet, still trying to track down bugs in SunSpider (raytrace, aes are acting up).

Comment 2

[Edwin Smith]

is this a dupe of 464476 (or vice versa?)

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

It wasn't intended to be a dupe but a preceding bug - but if the existing x64 code base is going to be scrapped then this can be closed.

The only thing that's important from this patch is the separation of LIR_float from LIR_quad, because a LIR_quad(0) could either be a NULL pointer or a 0.0 float.  TraceMonkey peeks into the LIR to determine this difference but on x64 it doesn't work.

Comment 4

[Edwin Smith]

ive got a working rewrite of the x64 backend and so far i havent had the need for LIR_float, so maybe i dont understand the current issue?

x64 can freely copy xmm<->gpr registers without storing to memory, which i take advantage of in asm_nongp_copy().  Floating point operations request XMM registers for their operands, so sometimes we will get into asm_quad() and the required register will already be XMM.  sometimes it will be GPR, either way it works.

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to comment #4)
> ive got a working rewrite of the x64 backend and so far i havent had the need
> for LIR_float, so maybe i dont understand the current issue?

It's an issue on TraceMonkey's end.  When speculating numeric types we look at:

> (i->isconstq() && ((d = i->constvalf()) == (jsdouble)(jsint)d)) 

If that's true, we demote to an integer.  This fails on x64 if the value is a 64-bit 0 intended as a NULL pointer.  Distinctly separating the types solved it.

If it's a problem I can add it back in later - I wouldn't let it block landing your x64 stuff.

Comment 6

[Brent Baker]

Does this patch need to be rebased now that the x64 nanojit has landed?

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

This patch is dead now that there's a new x64 port.