Bill Coffman <[EMAIL PROTECTED]> wrote:
> Currently, here's how the register allocator is doing.
> Failed Test Stat Wstat Total Fail Failed List of Failed
> -------------------------------------------------------------------------------
> t/library/dumper.t 5 1280 13 5 38.46% 1-2 5 8 13
> 4 tests and 51 subtests skipped.
> Failed 1/123 test scripts, 99.19% okay. 5/1956 subtests failed, 99.74% okay.
> I recall Leo, or someone, saying that the data dumper routines are not
> following the calling convention properly.
I didn't look too close, but it's probably only the entry points:
.sub _dumper
_global_dumper()
That's missing C<.param> statements, so there are none.
> I've learned a lot about how the compiler works at this point, and I'd
> like to contribute more :)
Great. Thanks.
> Would you like a patch? Should I fix the data dumper routines first?
Definitely - dumper.t tests are currently disabled, don't worry.
> What is all this talk about deferred registers? What should I do
> next?
"deferred registers" doesn't make bells ring. What do you mean with
that? - Send patch with explanation of algorithm.
> Yes, I think we are kind of doing this. It's best to pass the
> registers straight through though. Like when a variable will be used
> as a parameter, give it the appropriate reg num. Sort of outside the
> immediate scope of register coloring, but as I've learned, one must go
> a little beyond, to see the input and output for each sub.
Well, it's not really outside of register coloring. It's part of
parrot's calling conventions. You can think of it as part of the Parrot
machine ABI. When you write a compiler for darwin-PPC, you have to pass
function arguments in r3, r4, ... and you get a return value in r3. If
you don't do that, you'll not be able to make any C library call.
In Parrot we have similar calling conventions and the register allocator
must be aware of that. E.g. when you have:
some_function() # (i, j) = some_function()
$I0 = I5
$I1 = I6
you know that I5 and I6 are return results. The live range or the
previous usage of I5 and I6 is cut by the function call.
Using the return values directly is of course an optimization and not
strictly necessary, nethertheless the allocator has to be aware that the
function call invalidates previous I5 and I6.
> But the idea is to have each sub declare how many registers to
> save/restore.
Don't worry about save/restore. That's already changed. imcc doesn't
emit any savetop/restoretop or similar opcodes any more. Registers are
preserved now by allocating a new register frame for the subroutine.
> We can also minimize this number to match the physical architecture
> that parrot is running on (for an arch specific optimization).
Yes. I did that some time ago in imcc/jit.c, which produced register
mapping for the underlying hardware CPU. Parrot registers 0.. n-1 were
given negative numbers and src/jit.c used these directly as mapping for
CPU registers. This vastly reduced JIT startup time.
> Yes, yes, renaming! I want to do register renaming!
Go for it please.
> p31 holds all the spill stuff. It's a pain. Maybe I'll move that
> around, but if p31 is used, it means that there is no more room for
> symbols, in at least one of the reg sets.
I'd say that with register renaming, spilling will be very rare. But
there is of course no need to use P31 for it. If we really have to spill
we can optimize that a bit.
> - Bill Coffman
leo
