[llvm-dev] Allowing virtual registers after register allocation
Smith, Kevin B via llvm-dev
llvm-dev at lists.llvm.org
Thu Dec 10 10:04:49 PST 2015
>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.
>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
More information about the llvm-dev