517601 - TM merge: revive lirasm

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Graydon Hoare :graydon]

Attachment: Fix the breakage, further detach from tracemonkey environment

Poor old lirasm took a beating during this merge. The attached patch fixes the worst of the differences, as far as I can tell. It builds and passes its tests again anyway.

I'll have a go at a standalone makefile and configure script for the nanojit-central repository next.

Comment 1

[Jason Orendorff [:jorendorff]]

Comment on attachment 401557 [details] [diff] [review]
Fix the breakage, further detach from tracemonkey environment

r=me, no real comments.

>-VPATH		= @srcdir@
>+
>+VPATH		= $(srcdir)
>+VPATH		+= $(srcdir)/../nanojit

I don't really know what this does.

...I take it LIR_loop has been replaced by LIR_x and a patch() after compilation?

>-    AbiKind _abi;
>-    if (abi == "fastcall")
>+    AbiKind _abi = ABI_CDECL;

It seems like _abi is always assigned below. If so, I'd be happier without this initialization, as the compiler can then warn usefully if we introduce a bug.

>-    for (size_t i = 0; i < mCallInfos.size(); ++i)
>-        delete mCallInfos[i];

I guess the new allocator is an arena that gets blown away all at once later? Do you need to explicitly call any destructors, then?
Can the mLabelMap and so forth just be located in the Lirasm instead of being allocated?

Comment 2

[Graydon Hoare :graydon]

Thanks. In answer to your questions:

The VPATH addition accompanies the change to building lirasm with an explicit list of object files compiled "from nanojit", rather than linked against libjs. There is no dependence on the surrounding JS environment anymore (I hope).

The _abi change eliminates a "possible use before def" warning; the compiler is not smart enough to know that the bad() call in the else block is aborting.

The exact location of most of the auxiliary objects can change now, yes. This patch was an attempt at minimal updates to get it working again. A more extensive update would probably move the ownership around a bit, but I'm leaving that problem for another day.

Comment 3

[Graydon Hoare :graydon]

Oh, and yes, LIR_loop turned into ... a LIR_j I believe.

Comment 4

[Graydon Hoare :graydon]

http://hg.mozilla.org/tracemonkey/rev/2371aa917202

Comment 5

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/2371aa917202

Comment 6

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/8a5bccdbb7d0