llvm dev - Dec 2015 - 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.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

>-----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.

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

----- 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