search

arvindm95 / unladen-swallow

Automatically exported from code.google.com/p/unladen-swallow
Other
0 stars 0 forks source link

Make the stackpointer not escape #18

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
CALL_FUNCTION, CALL_FUNCTION_VAR_KW and UNPACK_SEQUENCE make the
stackpointer escape LLVM's pervue because their implementations (in C
functions) manipulate the stack directly. Getting rid of the direct
manipulation would allow LLVM to optimize more stack operations (and make
it easier to move away from the stack machine.)

Original issue reported on code.google.com by thomaswout@gmail.com on 21 Apr 2009 at 10:41

GoogleCodeExporter commented 8 years ago

Original comment by collinw on 27 May 2009 at 9:47

GoogleCodeExporter commented 8 years ago

Original comment by collinw on 29 May 2009 at 4:13

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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

GoogleCodeExporter commented 8 years ago 
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