Closed GoogleCodeExporter closed 8 years ago
Original comment by collinw
on 27 May 2009 at 9:47
Original comment by collinw
on 29 May 2009 at 4:13
Started in http://codereview.appspot.com/63178. It turns out that it's more
important
to expose the entire history of the stack pointer's value to LLVM than just to
keep
its address contained. With the entire history, LLVM can avoid loops popping
the stack
value and in some cases may be able to automatically turn our stack machine
into a
register machine. Line tracing is a particular problem, which we may solve by
jumping
back to the interpreter any time we discover that tracing is on.
Original comment by jyass...@gmail.com
on 1 Jun 2009 at 9:52
As of r637, we now jump back to the interpreter for tracing whenever possible.
This
didn't do much to execution speed, but it sped up startup time dramatically:
normal_startup:
Min: 25.606 -> 20.600: 24.30% faster
Avg: 28.970 -> 21.404: 35.35% faster
Significant (t=4.807616, a=0.95)
startup_nosite:
Min: 3.491 -> 2.511: 39.02% faster
Avg: 3.595 -> 2.671: 34.59% faster
Significant (t=23.521424, a=0.95)
I'm working on allowing LLVM to see the modifications UNPACK_SEQUENCE makes to
the stack pointer. This may increase icache pressure, but we'll see.
Original comment by collinw
on 19 Jun 2009 at 8:54
r665 stops the stack pointer from "escaping" in CALL_FUNCTION. The only
remaining
place is in CALL_FUNCTION_{VAR,KW,VAR_KW}, which isn't used much.
(UNPACK_SEQUENCE
writes to the stack, but doesn't actually modify the stack pointer.) If we see
CALL_FUNCTION_VAR_KW causing real code to miss optimizations, we should fix
that, but
until then, this is fixed.
Original comment by jyass...@gmail.com
on 22 Jun 2009 at 6:34
Original issue reported on code.google.com by
thomaswout@gmail.com
on 21 Apr 2009 at 10:41