Ian Piumarta <ian.piumarta at inria.fr> wrote:
> .L2337: <--- bytecodes that don't write the stack end by jumping here
>         movl    trueObj, %ebp           # code motion: movl/cmpl &true,x
>                                           out of the loop (*POINTLESS*)
> .L2369: <--- only ONE bytecode arrives here (it doesn't clobber ebp)
>         movl    falseObj, %ecx          # code motion: movl/cmpl
> &false,x
>                                           out of the loop (*POINTLESS*)
> .L2338: <--- only ONE bytecode arrives here (it doesn't clobber ebp or
> ecx)
>         jmp     *jumpTable.1(,%ebx,4)   # dispatch next bytecode
> 
> # bytecodes ...
> 
> If anything it's a worse disaster than occasionally spilling a
> register variable.  The vast majority of bytecodes are reloading
> trueObj and falseObj into registers on EVERY SINGLE DISPATCH.  While
> one can see the advantages of what the compiler is doing for
> `mostly-linear' programs, *any* interpreter is going to suffer *badly*
> from this kind of aggressive (and reckless) CSE.

Hi Ian,

I saw this problem in gcc 2.96 (or whatever comes with RedHat 7.0 - I'm
not at my computer now).  I worked around it in my BC/VI4 interpreter by
assigning trueObj and falseObj to local variables at the top of the
interpret function, and changing reference to them in bytecode methods
to use the local vars instead of the global ones.  I forget my reasoning
for trying this but it worked - no more preloading global or local
true/false objects into registers at the end of every bytecode case.

To avoid re-copying the globals into the locals every time interpret
calls out and returns (internalizeIPandSP), I assume trueObj and
falseObj will never move during a GC.  I enforce this when I translate
the image using the SystemTracer, by making sure trueObj and falseObj
are the first two objects in object memory (nothing will ever be freed
before it and compacted).  I guess we could remove this assumption and
add the re-copying to internalizeIPandSP.  The two extra copy
instructions would probably be negligible compared to the rest work
being done when calling out and returning.

Cheers,
Anthony