[kaffe] mipsel JIT3

Kevin D. Kissell kevink at mips.com
Sat Mar 6 01:39:02 PST 2004


> Notice the difference?  The "kaffe.def" calls do the pushargs before the 
> begin_func_sync and the "icode.c" calls do the pushargs after the 
> begin_func_sync.  Arghh!!

Now, if only I knw what "begin _func_sync" really meant, I'd know
whether that was really a problem!  ;o)

> > I could believe that
> > the hack below may have helped some bug that PPC was seeing,
> > and it might help MIPS as well, but if rreg_ideal_int() can be fatal, 
> > I would think that rreg_int() could be as well.
> 
> Yeah, I might've just gotten lucky somehow...

If the register already associated to the requesting slot is global,
or if its type is the same as that requested (for read use) or
its type is the same as requested and its reference count is
only one (for write use), you'd avoid going to the allocator
on a non-ideal rreg_mumble().  I suspect that covers more
than 50% of the dynamic instances of GPR allocation.
But on architures with distinct FPU registers (and that's
most architectures these days), you would lose a lot more 
often on requests for floating registers.

It's easy for me to say this as I sit here looking at sources
on a Windows box with neither the means nor the opportunity
to roll up my sleeves and do it myself, but I think that, rather
than avoid the use of the rreg_ideal_mumble()'s, we need
to fix the underlying problem, because it can happen anyway.

And, actually, looking at the slotRegister() code (which is 
what all the rreg_mumble_mumble() macros expand to)
it strikes me that I must have observed another bug when
I was tracing the TestNative regression test failures.
As I mentioned earlier, when the function call prologue
was being generated and the arguments that wouldn't
fit into the designated argument registers were being
pushed onto the stack, each push invoked rreg_mumble(),
and each time it returned a new register number, looping
through the full set of usable registers until it clobbered
the designated argument registers.  Given what I observed
above about slotRegister(), I don't understand why it is
that we never seemed to be able to re-use the register
binding to a slot.

Whether by fixing some underlying machinery, or by judicious
use of a fixed rreg_ideal_mumble(), we really ought to ensure
that the same temporary registers are used through the whole
argument push sequence.  It should be good for a measurable
performance increase.

            Regards,

            Kevin K.




More information about the kaffe mailing list