[LLVMdev] LLVM register number for MIPS DAGToDAG

Daniel Sanders Daniel.Sanders at imgtec.com
Mon Mar 2 08:05:15 PST 2015


You are currently printing LLVM's internal register numbers rather than the target register numbers. If you look at lib/Target/Mips/MipsGenRegisterInfo.inc (a generated file in your build directory), you should see that the numbers correspond to an enum value near the start of the file. In my build, MipsGenRegisterInfo.inc contains:
  namespace mips
  enum {
    V1 = 290,
V1 is another name for $3, so 290 is the correct register number for $3. You need to pass this number to MipsInstPrinter::getRegisterName() to get the name used in assembly but note that this is a many-to-one mapping. Both V0 and V0_64 will produce $3. Similarly F0, F0_HI, D0, and D0_64 will all produce $f0.

The internal register numbers are different from the target register numbers because it is important to keep track of how registers overlap with each other. For example, F0, F0_HI, D0, and D0_64 are all printed as $f0, but they have different uses:

·         F0 is a 32-bit floating point value.

·         D0 is a 64-bit floating point value that overlaps with F0 and F1. It's only used for 32-bit FPU's.

·         F0_HI the top 32-bits of a 64-bit floating point value. It's only used for 64-bit FPU's.

·         D0_64 is a 64-bit value that overlaps with F0, and F0_HI. It's only used for 64-bit FPU's.

Hope that helps.

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Ambuj Agrawal
Sent: 28 February 2015 16:33
To: Quentin Colombet
Cc: john.spelis at bluwirelesstechnology.com; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] LLVM register number for MIPS DAGToDAG

Thanks for your reply Quentin. I do understand that the registers are allocated much later in the pipeline.
I am assuming that the physical registers are allocated before MipsAsmPrinter class.
I am doing something like
  if (MI->getOpcode() == Mips::OPCODE) {
        unsigned n = MI->getNumOperands();
        for(unsigned i=0 ; i < n ; i++) {
            const MachineOperand &MO = MI->getOperand(i);
            if (MO.isReg())
                fprintf(stderr,"int i is %u and reg is %d\n",i, MO.getReg());
but I am still getting wrong physical register number.
For eg when the allocated register is 3 in assembly the output given by MO.getReg() is 290.
Any clues why is this the case?

On Fri, Feb 27, 2015 at 5:46 PM, Quentin Colombet <qcolombet at apple.com<mailto:qcolombet at apple.com>> wrote:

> On Feb 27, 2015, at 1:59 AM, Ambuj Agrawal <ambujbwt at gmail.com<mailto:ambujbwt at gmail.com>> wrote:
> Is it possible to get a register number to which the value is allocated to in MIPS in DAGToDAG class?
> More Specifically:
>                     SDValue Reg3 = Node->getOperand(3);
>                     if (RegisterSDNode *R = dyn_cast<RegisterSDNode>(Reg3))
>                     {
>                         op3 = cast<RegisterSDNode>(Reg3)->getReg();
>                         fprintf(stderr,"Op3 is register and regnum is %d\n",op3);
>                     }
>                     else if (ConstantSDNode *C = dyn_cast<ConstantSDNode>(Reg3))
>                     {
>                         op3 = C->getZExtValue();
>                         fprintf(stderr,"Op3 is constant and value is %d\n",op3);
>                     }
> When I run this code Reg3 is found out to be a ConstantSDNode but is stored in the register in assembly. I want to store the value in register but also need the register number to which the value is allocated.
The registers are allocated much later in the pipeline. At this stage, these are virtual registers.

What are you trying to achieved?


> Thanks,
> Ambuj Agrawal
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150302/12c75760/attachment.html>

More information about the llvm-dev mailing list