Spill location collision with loop created with LIR_j

RESOLVED WONTFIX

Status

Core Graveyard
Nanojit
--
enhancement
RESOLVED WONTFIX
10 years ago
4 years ago

People

(Reporter: dmandelin, Unassigned)

Tracking

unspecified
Future
Bug Flags:
in-testsuite ?
flashplayer-qrb +
flashplayer-triage +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Created attachment 343998 [details] [diff] [review]
Testcase patch for Tracemonkey

I'm trying to create a loop using LIR_j, and I seem to have found a bug where two values (LIns results) are spilled to the same memory location. The result is that the compiled code doesn't do what it should according to the LIR semantics--one of the values is overwritten.

I'm doing this as part of trying to use nanojit to compile regular expressions to native code. My patch to duplicate the error is attached. With this, you can get the error if you run with input:

    print("vax".match(/a/));

This input works correctly:

    print("ax".match(/a/));

The reason the first fails is that the values that collide are 'cp' (pointer to current string character being matches) and 'cp_end' (pointer to end of string). The collision causes the spilled value of 'cp_end' to be overwritten with the value of 'cp' on the first loop iteration. Thus, cp_end now points to the start of the string. More precisely, cp_end will point to the start of the string when it is refreshed on the second iteration. Then, cp, which now points to the second character, will be after cp_end, so the length test fails and the match fails.

The problem is apparent in the debug output (if you build my patched TM in a debug build):

        spill cpend
                   mov -20(ebp),ebx           ebx(cpend)
   ... (loop header is in here) ...
        restore cpend
                   mov edx,-20(ebp)           ebx(param1) esi(param2) edi(param3
        spill cp
                   mov -20(ebp),ecx           eax(state) ecx(cp) edx(cpend) ebx(
   ... (loop back edge here) ...

On the second iteration, 'restore cpend' actually loads the value of 'cp' from the previous iteration.
(Reporter)

Comment 1

10 years ago
Created attachment 343999 [details]
My debug output
(Reporter)

Updated

10 years ago
Blocks: 461050
(Reporter)

Comment 2

10 years ago
Removing dep for now as I am not currently using LIR_j loops in bug 461050.
No longer blocks: 461050

Updated

10 years ago
Flags: in-testsuite?
Flags: flashplayer-triage+
Flags: flashplayer-qrb?

Updated

9 years ago
Flags: flashplayer-qrb? → flashplayer-qrb+

Comment 3

9 years ago
Whats the status of this bug?

Updated

9 years ago
Severity: normal → enhancement
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Future

Updated

9 years ago
Component: JIT Compiler (NanoJIT) → Nanojit
Product: Tamarin → Core
QA Contact: nanojit → nanojit

Comment 4

8 years ago
LIR_live exists for the purpose of extending lifetimes of expressions that need to be alive thru the whole loop.  marking wontfix since this bug appears to be dead and LIR_live is the existing solution.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

4 years ago
Component: Nanojit → Nanojit
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.