On Thu, Aug 7, 2008 at 8:10 AM, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote: > > > On Thu, Aug 7, 2008 at 12:45 PM, Will Coleda <[EMAIL PROTECTED]> wrote: >> >> On Wed, Aug 6, 2008 at 3:30 PM, Jonathan Worthington <[EMAIL PROTECTED]> >> wrote: >> > Will Coleda wrote: >> >> >> >> Can you describe a situation where this occurs that isn't a bug in the >> >> register allocator? >> >> >> > >> > Yes. IIRC, it was added when I was working on the .Net bytecode >> > translator, >> > and it needed to take references to registers in callers. >> >> Being allowed to poke inside your caller's register set seems... evil? > > if the HLL compiler can make such an analysis (of liveliness), then it can > emit such hints to the register allocator. So it's not that evil imho.
One of the original points of IMCC is that this sort of register allocation is not something the HLL folks should be doing as it is a common bookeeping function. This position has been strengthened in the updated PIR PDD which removes any direct access to any particular register. Now you can't guarantee any particular register is ever used. Everything is now named access or $Temp registers, none of which is guaranteed to map to a particular parrot register. So, again, do we in parrot want to support the ability to dig into our callers register set and pull out a particular register since we have no way to say which register that is when we're using PIR? Even unique_reg just says 'the register doesn't change', not "it's PMC register 3" > then again, one might argue that the register allocator itself should be > smart enough to see that a certain object is being retrieved into a register > several times in the same block, and decide to optimize that by assigning a > register to it for the whole block. > kjs > >> >> Can you provide a working PIR example that shows this functionality? >> >> > If you're doing >> > that, you need to know that the register won't get re-used once the >> > reference has been taken, or you'll end up with a reference to the wrong >> > register. Named registers holding things that references were being >> > taken >> > to, were marked with :unique_reg, to make sure this didn't happen. >> > >> > It also, as Pm mentioned, works as a hint to the register allocator not >> > to >> > bother trying to allocate something that will have life over the entire >> > compilation unit anyway. >> > >> > Jonathan >> > >> > >> >> >> >> -- >> Will "Coke" Coleda > > -- Will "Coke" Coleda
