[llvm-dev] Allowing virtual registers after register allocation

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 10 12:11:16 PST 2015


----- Original Message -----
> From: "Kevin B via llvm-dev Smith" <llvm-dev at lists.llvm.org>
> To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>, llvm-dev at lists.llvm.org
> Sent: Thursday, December 10, 2015 12:04:49 PM
> Subject: Re: [llvm-dev] Allowing virtual registers after register allocation
> 
> >-----Original Message-----
> >From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> >Krzysztof Parzyszek via llvm-dev
> >Sent: Thursday, December 10, 2015 9:47 AM
> >To: llvm-dev at lists.llvm.org
> >Subject: Re: [llvm-dev] Allowing virtual registers after register
> >allocation
> >
> >On 12/10/2015 11:39 AM, Hal Finkel via llvm-dev wrote:
> >>
> >> But there is lots of code that assumes that it can iterate over
> >> all physical
> >registers in some class. My thought had been that you don't want to
> >introduce infinite physical register sets because this assumption of
> >enumerability is broken (as is the assumption that the size does not
> >dynamically change). Thoughts?
> >
> >The post-RA code may not be free from assumptions that all virtual
> >registers are gone.  For example, such code may not handle
> >subregisters,
> >since PhysReg:Sub can always be collapsed to another physical
> >register.
> >  For virtual registers, there is no such guarantee.
> >
> >I think it would be a lot clearer if we introduced infinite register
> >classes, with all the properties of physical registers (except those
> >obviously related to finiteness).  Having virtual registers after RA
> >sounds like a huge hack.
> 
> I definitely agree that having virtual regs after RA sounds like a
> hack.
> 
> But I also don't know why it would be desirable to introduce infinite
> register classes. The WebAsm folks are already saying that they
> would like to do register allocation to target a fixed/limited
> number (might be large though) of "virtual registers".  So, instead
> of calling these virtual registers, why not call them physical
> registers, and have a fixed number of them, that corresponds to the
> number that is desired to allocate to.  Or, you could have the
> number of registers to use be run-time selectable in some manner by
> just having the physical register set be larger than is ever planned
> to be used by that particular CG, and having run-time controls to
> restrict the set of allocatable physical registers.

You're right that we don't really want infinite register classes, but rather, we want "expandable" ones. Making extra-large register classes that are restricted by having most of the registers in the reserved set, however, seems just as much a hack (and a worse one in many ways).

I'd certainly not object to some kind of dynamically-sized "physical" register class concept.

 -Hal

> 
> Kevin Smith
> 
> >
> >-Krzysztof
> >
> >--
> >Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >hosted by The Linux Foundation
> >_______________________________________________
> >LLVM Developers mailing list
> >llvm-dev at lists.llvm.org
> >http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory


More information about the llvm-dev mailing list