Closed
Bug 585915
Opened 15 years ago
Closed 15 years ago
JM: remove stores for loop condition values
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
People
(Reporter: jandem, Assigned: jandem)
References
Details
Attachments
(1 file)
|
798 bytes,
patch
|
dvander
:
review+
|
Details | Diff | Splinter Review |
Consider a loop like this:
for(var j=0; j<100
| Assignee | ||
Comment 1•15 years ago
|
||
Argh, second part was not submitted.
But for this loop:
for(var j=0; j<100000; j++) {} we generate this code:
0xf7fc831b: mov 0x78(%ebx),%edx
0xf7fc831e: mov %edx,%esi
0xf7fc8320: add $0x1,%esi
0xf7fc8323: jo 0xf7fc86e2
0xf7fc8329: mov %esi,0x78(%ebx)
0xf7fc832c: mov 0x7c(%ebx),%edi
0xf7fc832f: mov 0x78(%ebx),%esi
0xf7fc8332: cmp $0xffff0001,%edi
0xf7fc8338: jne 0xf7fc8714
-> 0xf7fc833e: movl $0xffff0001,0x8c(%ebx)
-> 0xf7fc8348: movl $0xf4240,0x88(%ebx)
-> 0xf7fc8352: mov %esi,0x80(%ebx)
-> 0xf7fc8358: mov %edi,0x84(%ebx)
0xf7fc835e: cmp $0xf4240,%esi
0xf7fc8364: jl 0xf7fc82f8
The marked lines should be removed.
| Assignee | ||
Comment 2•15 years ago
|
||
This patch reduces the loop to:
0xf7fc831b: mov 0x78(%ebx),%edx
0xf7fc831e: mov %edx,%esi
0xf7fc8320: add $0x1,%esi
0xf7fc8323: jo 0xf7fc86a2
0xf7fc8329: mov %esi,0x78(%ebx)
0xf7fc832c: mov 0x7c(%ebx),%edi
0xf7fc832f: mov 0x78(%ebx),%esi
0xf7fc8332: cmp $0xffff0001,%edi
0xf7fc8338: jne 0xf7fc86d4
0xf7fc833e: cmp $0xf4240,%esi
0xf7fc8344: jl 0xf7fc82f8
This passes trace-tests. Reduces time for an empty-loop microbenchmark from 390ms. to 300ms. Probably a few ms. on SS/V8 on awfy.
| Assignee | ||
Updated•15 years ago
|
Blocks: JaegerSpeed
Comment on attachment 464373 [details] [diff] [review]
Patch
Nice! The sub-optimal ordering looks like a regression from bug 579225.
http://hg.mozilla.org/users/danderson_mozilla.com/moo/rev/1fa8cdc8b328
Attachment #464373 -
Flags: review?(dvander) → review+
| Assignee | ||
Comment 4•15 years ago
|
||
Thanks, marking fixed then.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Looks like this was about 6ms on regress-x86 (2ms on main, might be noisy).
You need to log in
before you can comment on or make changes to this bug.
Description
•