[llvm] r177423 - Prepare to make r0 an allocatable register on PPC

[Hal Finkel]

----- Original Message -----
> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Tuesday, March 19, 2013 3:58:27 PM
> Subject: Re: [llvm] r177423 - Prepare to make r0 an allocatable register on PPC
> 
> 
> On Mar 19, 2013, at 11:58 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > ----- Original Message -----
> >> From: "Hal Finkel" <hfinkel at anl.gov>
> >> To: llvm-commits at cs.uiuc.edu
> >> Sent: Tuesday, March 19, 2013 1:51:05 PM
> >> Subject: [llvm] r177423 - Prepare to make r0 an allocatable
> >> register on PPC
> >> 
> >> Author: hfinkel
> >> Date: Tue Mar 19 13:51:05 2013
> >> New Revision: 177423
> >> 
> >> URL: http://llvm.org/viewvc/llvm-project?rev=177423&view=rev
> >> Log:
> >> Prepare to make r0 an allocatable register on PPC
> >> 
> >> Currently the PPC r0 register is unconditionally reserved. There
> >> are
> >> two reasons
> >> for this:
> >> 
> >> 1. r0 is treated specially (as the constant 0) by certain
> >> instructions, and so
> >>    cannot be used with those instructions as a regular register.
> >> 
> >> 2. r0 is used as a temporary register in the CR-register spilling
> >> process
> >>    (where, under some circumstances, we require two GPRs).
> >> 
> >> This change addresses the first reason by introducing a restricted
> >> register
> >> class (without r0) for use by those instructions that treat r0
> >> specially. These
> >> register classes have a new pseudo-register, ZERO, which
> >> represents
> >> the r0-as-0
> >> use. This has the side benefit of making the existing target code
> >> simpler (and
> >> easier to understand), and will make it clear to the register
> >> allocator that
> >> uses of r0 as 0 don't conflict will real uses of the r0 register.
> >> 
> >> Once the CR spilling code is improved, we'll be able to allocate
> >> r0.
> >> 
> >> Adding these extra register classes, for some reason unclear to
> >> me,
> >> causes
> >> requests to the target to copy 32-bit registers to 64-bit
> >> registers.
> >> The
> >> resulting code seems correct (and causes no test-suite failures),
> >> and
> >> the new
> >> test case covers this new kind of asymmetric copy.
> > 
> > Jakob,
> > 
> > I'd appreciate some insight into why this happens. Specifically, if
> > you run the test case with -debug, you'll see this:
> > ********** EXPANDING POST-RA PSEUDO INSTRS **********
> > ********** Function: main
> > real copy:   %X3<def> = COPY %R29<kill>
> > replaced by: %X3<def> = OR8_32 %R29, %R29<kill>
> > 
> > %R3 is a subregister of %X3, and if %X3 is available than so is
> > %R3, and I don't understand why it now wants to do this whereas it
> > did not previously. Nevertheless, everything seems okay.
> 
> This way of handling the zero register is the right way to do it, and
> your register classes look good. However, dealing with overlapping
> register classes sometimes requires careful code, and PPC may have
> been able to get away with old sloppy code until now.
> 
> Sloppy old code will often compare register classes by identity (with
> ==). That is usually not correct. You almost always want to use
> RC.hasSubClassEq() instead. Looking through the PPC code, I don't
> see anything suspicious, though.
> 
> It is also possible that something weird is happening because you put
> the same ZERO register in GPRC and G8RC. Try with separate 32 and
> 64-bit ZERO registers.

I tried this, and it does not change anything. I still get these odd copies.

Thanks again,
Hal

> 
> /jakob
> 
>