On Fri, Aug 8, 2008 at 12:57 PM, Patrick R. Michaud <[EMAIL PROTECTED]>wrote:

> On Thu, Aug 07, 2008 at 10:15:24AM -0400, Will Coleda wrote:
> > Now, if the problem is that the register allocator is broken, then
> > let's fix the register allocator. If :unique_reg is just a workaround
> > because fixing it is hard, let's document it as deprecated with the
> > expectation that it will be removed when the allocator is no longer
> > broken.
>
> Here's my slightly different interpretation:
>
> Before we had variable register frames, the register allocator
> was something of a necessary evil, because we needed something
> that could fit a large number of symbolic registers into a
> fixed number of absolute registers.
>
> However, now that we have variable register frames, the register
> allocator is really more of an optimizer than anything else -- i.e.,
> it allows our code to run using fewer registers.  And as with
> any other optimization, we ought to provide the compiler writers
> with an option to turn the optimization off.  This is effectively
> what :unique_reg does on a per-symbol basis.
>
> Of course, ":unique_reg" on individual symbols might not be
> the best way to achieve this, but it does at least have
> historical precedent.  If we eliminate ":unique_reg", I'd
> still like to have a way to generate PIR code where I know
> that the register allocator isn't re-using registers or
> doing other fancy allocation.
>
> Pm


Well, at least I've seen some good reasons to keep :unique_reg around;
viewing the pir compiler as an assembler (which it is, in the end, albeit a
fancy one), :unique_reg is just a directive.

Once the whole register allocation stuff is revisited (and I'm sure imcc's
should be tested for bugs), this can be reconsidered.

For now, this thread provided enough information to update pdd19. I will do
this sometime soon. Thanks for all the feedback.

kjs

Reply via email to