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

[Jakob Stoklund Olesen]

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.

/jakob