[This is a spin-off of bug 378793 comment 55] Due to register pressure on x86 using a local JSRuntime *rt to store cx->runtime is counterproductive since a compiler will use a stack slot to store cx->runtime while for cx the compiler can assign a register. Thus to access cx->runtime the compiler uses similar offset(cx_register) or offset(stack_register) instructions and initial storage of cx->runtime in the stack slot for rt is just a waste of space. I also suspect that even on more register friendly architectures then x86 using rt locals can, in fact, lead to code bloat since the compiler will have to preserve the register when calling a function from a different compilation unit. In this case the compiler can not assume that cx->runtime is not modified so it is not possible to use cx->runtime to reload rt register if the latter was overwritten.
Created attachment 268473 [details] [diff] [review] implementation v1 The patch replaces rt via cx->runtime in the interpreter and saves 30-40 bytes from stripped jsinter.o with GCC 4.1.2 at -O, -O2, -Os when targeting a generic 586 CPU. With explicit -march=pentium-m the difference growth to 50-60 bytes. It would be interesting to know the results on x64.
With VC8 /O2 for x86 the patch increases the size of jsinterp.obj by 6 bytes. There are two more debug-only uses of rt in js_interpret in JS_RUNTIME_METER macros.
Comment on attachment 268473 [details] [diff] [review] implementation v1 Waiting for new patch per Seno.Aiko's comment. /be
I am not working on the bug right now.