[llvm-commits] [llvm] r140319 - /llvm/trunk/lib/Target/Mips/MipsRegisterInfo.td

Akira Hatanaka ahatanak at gmail.com
Thu Sep 22 13:41:35 PDT 2011


I have a question about subreg index.

I am going to add the D_64 FP registers to the same register file that
has the 16 64-bit registers consisting of a pair of 32-bit FP register
(this makes code simpler in other places). The register file
definition will look like this:

def AFGR64 : RegisterClass<"Mips", [f64], 64, (add
  // Return Values and Arguments
  D0, D1, D6, D7,
  // Not preserved across procedure calls
  D2, D3, D4, D5, D8, D9,
  // Callee save
  D10, D11, D12, D13, D14, D15,

  D0_64, D1_64, D2_64, D3_64, D4_64, D5_64, D6_64, D7_64,
  D8_64, D9_64, D10_64, D11_64, D12_64, D13_64, D14_64, D15_64,
  D16_64, D17_64, D18_64, D19_64, D20_64, D21_64, D22_64, D23_64,
  D24_64, D25_64, D26_64, D27_64, D28_64, D29_64, D30_64, D31_64)> {
  let SubRegClasses = [(FGR32 sub_fpeven, sub_fpodd)];
}

In this case, is it still correct to use sub_32 in D*_64 64-bit FP
register definitions or should I be using the same subreg indices
(sub_fpeven) that the paired registers use (perhaps renaming
sub_fpeven and sub_fpodd)?

On Thu, Sep 22, 2011 at 11:26 AM, Akira Hatanaka <ahatanak at gmail.com> wrote:
> I have fixed this in r140324.
> Thank you for your comment.
>
> On Thu, Sep 22, 2011 at 11:08 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>>
>> On Sep 22, 2011, at 10:57 AM, Akira Hatanaka wrote:
>>
>>> Author: ahatanak
>>> Date: Thu Sep 22 12:57:32 2011
>>> New Revision: 140319
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=140319&view=rev
>>> Log:
>>> Define a new sub-register index sub_32 for accessing the 32-bit sub-register of
>>> a 64-bit integer register. Move the subreg index definitions to the beginning
>>> of the file.
>>
>> Hi Akira,
>>
>> You should consider using sub_32 for the floating point registers as well.
>>
>> The sub_fpeven sub-registers on the D*_64 registers is a little confusing:
>>
>> (sub_fpeven D1_64) = F1 which isn't an even register.
>>
>> /jakob
>>
>>
>



More information about the llvm-commits mailing list