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)
Core Graveyard
Nanojit
Tracking
(Not tracked)
RESOLVED
WONTFIX
Future
People
(Reporter: dmandelin, Unassigned)
Details
Attachments
(2 files)
6.86 KB,
patch
|
Details | Diff | Splinter Review | |
7.66 KB,
text/plain
|
Details |
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•16 years ago
|
||
Reporter | ||
Comment 2•16 years ago
|
||
Removing dep for now as I am not currently using LIR_j loops in bug 461050.
No longer blocks: 461050
Updated•15 years ago
|
Flags: in-testsuite?
Flags: flashplayer-triage+
Flags: flashplayer-qrb?
Comment 3•15 years ago
|
||
Whats the status of this bug?
Updated•15 years ago
|
Severity: normal → enhancement
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Future
Updated•14 years ago
|
Component: JIT Compiler (NanoJIT) → Nanojit
Product: Tamarin → Core
QA Contact: nanojit → nanojit
Comment 4•14 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
Closed: 14 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•10 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•