Closed Bug 531165 Opened 12 years ago Closed 12 years ago

TM: move SoftFloatFilter upstream of CseFilter

Categories

(Core :: JavaScript Engine, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta5-fixed
fennec 1.0+ ---

People

(Reporter: gal, Assigned: n.nethercote)

References

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

I am filing this as a TM big, but might be general nanojit issue. We can move it over alter.

>	mozjs.dll!NanoAssertFail(void) Line: 71, Byte Offsets: 0x04	C++
 	mozjs.dll!nanojit::LIns::callInfo(void) Line: 974, Byte Offsets: 0x4c	C++
 	mozjs.dll!nanojit::LIns::argc(void) Line: 963, Byte Offsets: 0x18	C++
 	mozjs.dll!nanojit::LInsHashSet::findCall(nanojit::LIns* ins = 0x62bb4ba8) Line: 1383, Byte Offsets: 0x18	C++
 	mozjs.dll!nanojit::LInsHashSet::grow(nanojit::LInsHashKind kind = 0x00000007) Line: 1167, Byte Offsets: 0x1d8	C++
 	mozjs.dll!nanojit::LInsHashSet::add(nanojit::LInsHashKind kind = 0x00000007, nanojit::LIns* ins = 0x631b3f18, unsigned int k = 0x00000034) Line: 1182, Byte Offsets: 0x124	C++
 	mozjs.dll!nanojit::CseFilter::insCall(nanojit::CallInfo* ci = 0x7964b224, nanojit::LIns** args = 0x1bbc48d8) Line: 1966, Byte Offsets: 0xd8	C++
 	mozjs.dll!nanojit::LirWriter::insCall(nanojit::CallInfo* call = 0x7964b224, nanojit::LIns** args = 0x1bbc48d8) Line: 1040, Byte Offsets: 0x44	C++
 	mozjs.dll!FuncFilter::insCall(nanojit::CallInfo* ci = 0x7964b224, nanojit::LIns** args = 0x1bbc48d8) Line: 1934, Byte Offsets: 0x6f8	C++
 	mozjs.dll!nanojit::LirWriter::insCall(nanojit::CallInfo* call = 0x7964b224, nanojit::LIns** args = 0x1bbc48d8) Line: 1040, Byte Offsets: 0x44	C++
 	mozjs.dll!TraceRecorder::unbox_jsval(int v = 0x00000401, nanojit::LIns* v_ins = 0x631b3eb0, VMSideExit* exit = 0x63383c30) Line: 9367, Byte Offsets: 0x224	C++
 	mozjs.dll!TraceRecorder::prop(JSObject* obj = 0x01de2600, nanojit::LIns* obj_ins = 0x631b3e2c, unsigned long int* slotp = 0x00000000, nanojit::LIns** v_insp = 0x00000000, int* outp = 0x62bda54c) Line: 12529, Byte Offsets: 0x91c	C++
 	mozjs.dll!TraceRecorder::getProp(JSObject* obj = 0x01de2600, nanojit::LIns* obj_ins = 0x631b3e2c) Line: 12674, Byte Offsets: 0xb0	C++
 	mozjs.dll!TraceRecorder::record_JSOP_GETTHISPROP(void) Line: 14199, Byte Offsets: 0xb4	C++
 	mozjs.dll!TraceRecorder::monitorRecording(JSOp op = 0x000000d1) Line: 524, Byte Offsets: 0x23f8	C++
 	mozjs.dll!js_Interpret(JSContext* cx = 0x6161c000) Line: 78, Byte Offsets: 0xa80	C++
 	mozjs.dll!js_Invoke(JSContext* cx = 0x6161c000, unsigned int argc = 0x00000002, int* vp = 0x62bda220, unsigned int flags = 0x00000000) Line: 1384, Byte Offsets: 0xc4c	C++
 	mozjs.dll!js_fun_apply(JSContext* cx = 0x6161c000, unsigned int argc = 0x00000002, int* vp = 0x62bda1e8) Line: 2041, Byte Offsets: 0x418	C++
 	mozjs.dll!js_Interpret(JSContext* cx = 0x6161c000) Line: 2271, Byte Offsets: 0x15f70	C++
 	mozjs.dll!js_Invoke(JSContext* cx = 0x6161c000, unsigned int argc = 0x00000002, int* vp = 0x62bda158, unsigned int flags = 0x00000000) Line: 1384, Byte Offsets: 0xc4c	C++
 	mozjs.dll!js_fun_apply(JSContext* cx = 0x6161c000, unsigned int argc = 0x00000002, int* vp = 0x62bda120) Line: 2041, Byte Offsets: 0x418	C++
 	mozjs.dll!js_Interpret(JSContext* cx = 0x6161c000) Line: 2271, Byte Offsets: 0x15f70	C++
 	mozjs.dll!js_Invoke(JSContext* cx = 0x6161c000, unsigned int argc = 0x00000001, int* vp = 0x62bda064, unsigned int flags = 0x00000000) Line: 1384, Byte Offsets: 0xc4c	C++
 	mozjs.dll!js_fun_apply(JSContext* cx = 0x6161c000, unsigned int argc = 0x00000001, int* vp = 0x62bda02c) Line: 2041, Byte Offsets: 0x418	C++
 	mozjs.dll!js_Interpret(JSContext* cx = 0x6161c000) Line: 2271, Byte Offsets: 0x15f70	C++
 	mozjs.dll!js_Invoke(JSContext* cx = 0x6161c000, unsigned int argc = 0x00000001, int* vp = 0x62bda020, unsigned int flags = 0x00000000) Line: 1384, Byte Offsets: 0xc4c	C++
 	xul.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS* wrapper = 0x629757c0, unsigned short methodIndex = 0x0003, XPTMethodDescriptor* info = 0x61918c40, nsXPTCMiniVariant* nativeParams = 0x1bbcd2b0) Line: 1696, Byte Offsets: 0x1338	C++
 	xul.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex = 0x0003, XPTMethodDescriptor* info = 0x61918c40, nsXPTCMiniVariant* params = 0x1bbcd2b0) Line: 570, Byte Offsets: 0x7c	C++
 	xul.dll!PrepareAndDispatch(nsXPTCStubBase* self = 0x62b31c10, unsigned int methodIndex = 0x00000003, unsigned int* args = 0x1bbcd39c) Line: 109, Byte Offsets: 0x400	C++
 	0x7b5065c0
14:46:52 <crowder> -		this	0x62bb4ba8 {lastWord={...} dummy=0x72000000}	nanojit::LIns*
14:46:52 <crowder> -		lastWord	{arIndex=0x00000000 reg=0x00000000 used=0x00000000 ...}	nanojit::Reservation
14:46:55 <crowder> 		arIndex	0x00000000	unsigned int
14:46:58 <crowder> 		reg	0x00000000	nanojit::Register
14:47:00 <crowder> 	used	0x00000000	unsigned int
14:47:03 <crowder> 		opcode	0x00000072	nanojit::LOpcode
14:47:05 <crowder> 		dummy	0x72000000 {void*}	void*
opcode 0x72 is LIR_qlo
Very likely a dup of bug 527754.
Depends on: 527754
We use this bug to fix the TM side (switch filter ordering). Assigning to Nick.
Assignee: general → nnethercote
Severity: normal → major
tracking-fennec: --- → ?
Priority: -- → P2
Attached patch patchSplinter Review
Should fix it, but untested on ARM.  bcrowder, can you please test?
Attachment #414575 - Flags: review?
Attachment #414575 - Flags: review? → review?(crowder)
Blocks: 527754
No longer depends on: 527754
This might be a test case that triggers the bug (please try).

var a = [];
for (var i = 0; i < 10; ++i) {
    a[0] = Math.sin(5) + Math.sin(5);
}
Summary: TM: non-call LIns in call CSE hash table [nanojit, ARM] → TM: move SoftFloatFilter upstream of CseFilter
Comment on attachment 414575 [details] [diff] [review]
patch

stealing this one. crowder, can you verify that the test case breaks you, and the patch (with the bug we depend on) fixes it?
Attachment #414575 - Flags: review?(crowder) → review+
There is no proof this affects 1.9.2 but it might. We have an improved CSE filter on TM that exposes this bug. We should switch the filter around for 1.9.2 just to be safe.
Flags: blocking1.9.2?
The testcase from comment #6 does not trigger the assertion for me.
The assertion I was getting on startup is, however, cured by this patch.  This should block Fennec for WinMo.
tracking-fennec: ? → 1.0+
I think we should take this, it's small and fixes at least one serious ARM problem.  Let's get it to mc and 1.9.2 ASAP, please.
Flags: blocking1.9.2? → blocking1.9.2+
The ARM problem doesn't manifest without bug 502778's patch, AFAIK, but I can't guarantee that.  And this patch is small and low-risk, so I agree it's a good candidate for 1.9.2.

There are several other related CseFilter changes (bug 502778, bug 527754, bug 524632, the first two of which are in TM) but they are less appropriate for 1.9.2, being bigger changes and more performance-oriented.
http://hg.mozilla.org/mozilla-central/rev/9f9e62a9b6a5
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.