llvm dev - Oct 2017 - RFC: Adding bit to register MachineOperands to allow post-RA register renaming

Hi All,

Currently, changing register assignments of definitions after register 
allocation is not safe because there is no way to know which register 
definitions were physical registers before RA (e.g. to meet ABI or ISA 
constraints) and thus should not be changed.  I'd like to propose adding 
a bit to MachineOperand (by overloading the meaning of the IsKill bit 
for defs, so no extra storage would be required), that tracks whether a 
given register definition was a virtual register before RA.  I'll throw 
out 'IsRenameable' for a potential name.

Register definitions created with virtual registers would have this bit 
set.  This bit should be verifiable until after RA.  Register 
definitions created after RA (presumably with physical registers) would 
not have this bit set.  I believe the only potential for this bit to be 
set incorrectly (and not be caught be verification) would be if a 
post-RA pass was already renaming a register definition from a 
previously virtual register to a previously non-virtual register, which 
would arguably be a bug already.

We have encountered several potential uses for this bit.  For example, 
the MachineCopyPropagation changes I have been working on to forward 
register COPYs would likely be greatly simplified if this bit were 
available.  Other passes, like AArch64LoadStoreOptimizer, which run 
post-RA so as not to overly-restrict the register allocator, could be 
made to catch more cases if renaming of load instructions could be done 
safely.

-- 
Geoff Berry
Employee of Qualcomm Datacenter Technologies, Inc.
  Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code 
Aurora Forum, a Linux Foundation Collaborative Project.

Hi Geoff,

The principle sounds reasonable but it raises the question of proper APIs to
query that. E.g., when I am looking at a use, how would we know that this is
okay to rename? In other words, what API do we provide for such use cases.

Also, what do we do with registers that don’t have definition? For instance, a
function live-ins register, a reserved register, and so on.

Cheers,
-Quentin
> On Oct 25, 2017, at 10:27 AM, Geoff Berry <gberry at codeaurora.org>
wrote:
> 
> Hi All,
> 
> Currently, changing register assignments of definitions after register
allocation is not safe because there is no way to know which register
definitions were physical registers before RA (e.g. to meet ABI or ISA
constraints) and thus should not be changed.  I'd like to propose adding a
bit to MachineOperand (by overloading the meaning of the IsKill bit for defs, so
no extra storage would be required), that tracks whether a given register
definition was a virtual register before RA.  I'll throw out
'IsRenameable' for a potential name.
> 
> Register definitions created with virtual registers would have this bit
set.  This bit should be verifiable until after RA.  Register definitions
created after RA (presumably with physical registers) would not have this bit
set.  I believe the only potential for this bit to be set incorrectly (and not
be caught be verification) would be if a post-RA pass was already renaming a
register definition from a previously virtual register to a previously
non-virtual register, which would arguably be a bug already.
> 
> We have encountered several potential uses for this bit.  For example, the
MachineCopyPropagation changes I have been working on to forward register COPYs
would likely be greatly simplified if this bit were available.  Other passes,
like AArch64LoadStoreOptimizer, which run post-RA so as not to overly-restrict
the register allocator, could be made to catch more cases if renaming of load
instructions could be done safely.
> 
> -- 
> Geoff Berry
> Employee of Qualcomm Datacenter Technologies, Inc.
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.

Forgive me if these questions are naive or if I'm misunderstanding
something. I'm certainly very interested in seeing the
MachineCopyPropagation patch finally land and stick.

1. Wouldn't function live-ins and reserved registers have started life as
physical registers already? For example, wouldn't a live-in be a copy from
a physical register to a virtual one allowing the flag to be set correctly
on the def? A reserved register on the other hand just seems like something
we shouldn't touch, doesn't it?
2. I must admit that I don't really know how Aggressive Anti Dependence
Breaker works, but doesn't it already rename registers? How does it know
which ones are safe to rename and which aren't?

On Wed, Oct 25, 2017 at 10:20 PM, Quentin Colombet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Geoff,
>
> The principle sounds reasonable but it raises the question of proper APIs
> to query that. E.g., when I am looking at a use, how would we know that
> this is okay to rename? In other words, what API do we provide for such use
> cases.
>
> Also, what do we do with registers that don’t have definition? For
> instance, a function live-ins register, a reserved register, and so on.
>
> Cheers,
> -Quentin
>
> > On Oct 25, 2017, at 10:27 AM, Geoff Berry <gberry at
codeaurora.org> wrote:
> >
> > Hi All,
> >
> > Currently, changing register assignments of definitions after register
> allocation is not safe because there is no way to know which register
> definitions were physical registers before RA (e.g. to meet ABI or ISA
> constraints) and thus should not be changed.  I'd like to propose
adding a
> bit to MachineOperand (by overloading the meaning of the IsKill bit for
> defs, so no extra storage would be required), that tracks whether a given
> register definition was a virtual register before RA.  I'll throw out
> 'IsRenameable' for a potential name.
> >
> > Register definitions created with virtual registers would have this
bit
> set.  This bit should be verifiable until after RA.  Register definitions
> created after RA (presumably with physical registers) would not have this
> bit set.  I believe the only potential for this bit to be set incorrectly
> (and not be caught be verification) would be if a post-RA pass was already
> renaming a register definition from a previously virtual register to a
> previously non-virtual register, which would arguably be a bug already.
> >
> > We have encountered several potential uses for this bit.  For example,
> the MachineCopyPropagation changes I have been working on to forward
> register COPYs would likely be greatly simplified if this bit were
> available.  Other passes, like AArch64LoadStoreOptimizer, which run post-RA
> so as not to overly-restrict the register allocator, could be made to catch
> more cases if renaming of load instructions could be done safely.
> >
> > --
> > Geoff Berry
> > Employee of Qualcomm Datacenter Technologies, Inc.
> > Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the Code
> Aurora Forum, a Linux Foundation Collaborative Project.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171026/03fed3f5/attachment.html>