Closed Bug 460892 Opened 16 years ago Closed 14 years ago

Spill location collision with loop created with LIR_j

Categories

(Core Graveyard :: Nanojit, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: dmandelin, Unassigned)

Details

Attachments

(2 files)

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.
Attached file My debug output
Blocks: 461050
Removing dep for now as I am not currently using LIR_j loops in bug 461050.
No longer blocks: 461050
Flags: in-testsuite?
Flags: flashplayer-triage+
Flags: flashplayer-qrb?
Flags: flashplayer-qrb? → flashplayer-qrb+
Whats the status of this bug?
Severity: normal → enhancement
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Future
Component: JIT Compiler (NanoJIT) → Nanojit
Product: Tamarin → Core
QA Contact: nanojit → nanojit
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
Closed: 14 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: