llvm dev - Sep 2008 - [LLVMdev] Custom Opcodes versus built-in opcodes

I am using lowering instructions and using custom opcodes that I can
more easily directly map to my backend. These opcodes are then used to
emit a custom set of instructions into the MachineBasicBlock. I've been
able to get one to work correctly, however, I've ran into an issue where
my second one is being confused as a FRAMEADDR opcode instead of my
opcode.

DValue InstTargetLowering::LowerBR_CC(SDValue Op, SelectionDAG& DAG){

MVT VT = Op.getValueType();

            SDValue Chain = Op.getOperand(0);

            SDValue LHS   = Op.getOperand(2);

            SDValue RHS   = Op.getOperand(3);

            SDValue Jump  = Op.getOperand(4);

            bool logical_nz = getLogicalNZ(cmpOpcode);

            SDValue CmpValue; 

            unsigned int brOpcode = CUSTOM::BRANCH_NZERO;

           CmpValue = DAG.getNode(CUSTOM::CMP, LHS.getValueType(),
Chain, DAG.getConstant(cmpOpcode, MVT::i32), LHS, RHS);

            return DAG.getNode(brOpcode, VT, Chain, Jump, CmpValue);
}

 

What I want to happen is to take the branch w/ condition codes and
convert it into a comparison and then a branch based on the result to
the BasicBlock in the Jump SDValue. What I expect to occur after this
function returns is for the SDValue that I created to be matched with my
BRANCH_NZERO instruction in my InstrInfo.td file. Instead what is
occurring is that it is mapping it for some reason to the FRAMEADDR
built-in instruction and running LowerFRAMEADDR. Both instructions are
enumerated to the same value, but they are part of different namespaces.

 

Any idea on how I can resolve this issue?

 

Thanks,

 

Micah Villmow

Systems Engineer

Advanced Technology & Performance

Advanced Micro Devices Inc.

4555 Great America Pkwy,

Santa Clara, CA. 95054

P: 408-572-6219

F: 408-572-6596

 

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

On Thu, Sep 18, 2008 at 4:04 PM, Villmow, Micah <Micah.Villmow at amd.com>
wrote:
> I am using lowering instructions and using custom opcodes that I can more
> easily directly map to my backend. These opcodes are then used to emit a
> custom set of instructions into the MachineBasicBlock. I've been able
to get
> one to work correctly, however, I've ran into an issue where my second
one
> is being confused as a FRAMEADDR opcode instead of my opcode.
>
[snip]
>
> What I want to happen is to take the branch w/ condition codes and convert
> it into a comparison and then a branch based on the result to the
BasicBlock
> in the Jump SDValue. What I expect to occur after this function returns is
> for the SDValue that I created to be matched with my BRANCH_NZERO
> instruction in my InstrInfo.td file. Instead what is occurring is that it
is
> mapping it for some reason to the FRAMEADDR built-in instruction and
running
> LowerFRAMEADDR. Both instructions are enumerated to the same value, but
they
> are part of different namespaces.
>
That's the problem. The "LowerFRAMEADDR" is called depending on
the
enumeration's value, not on the namespace it's in. I can think of two
ways to solve this:

a) Change the enumeration of your BRANCH_NZERO instructions, or
2) Add your BRANCH_NZERO to the same namespace as FRAMEADDR.

-bw

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Bill Wendling
Sent: Thursday, September 18, 2008 4:16 PM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes

On Thu, Sep 18, 2008 at 4:04 PM, Villmow, Micah <Micah.Villmow at amd.com>
wrote:
> I am using lowering instructions and using custom opcodes that I can
more
> easily directly map to my backend. These opcodes are then used to emit
a
> custom set of instructions into the MachineBasicBlock. I've been able
to get
> one to work correctly, however, I've ran into an issue where my second
one
> is being confused as a FRAMEADDR opcode instead of my opcode.
>
[snip]
>
> What I want to happen is to take the branch w/ condition codes and
convert
> it into a comparison and then a branch based on the result to the
BasicBlock
> in the Jump SDValue. What I expect to occur after this function
returns is
> for the SDValue that I created to be matched with my BRANCH_NZERO
> instruction in my InstrInfo.td file. Instead what is occurring is that
it is
> mapping it for some reason to the FRAMEADDR built-in instruction and
running
> LowerFRAMEADDR. Both instructions are enumerated to the same value,
but they
> are part of different namespaces.
>
That's the problem. The "LowerFRAMEADDR" is called depending on
the
enumeration's value, not on the namespace it's in. I can think of two
ways to solve this:

a) Change the enumeration of your BRANCH_NZERO instructions, or
2) Add your BRANCH_NZERO to the same namespace as FRAMEADDR.

The problem with both of these solutions is that the opcodes are
dynamically generated with tablegen and thus I cannot change the
enumeration as I don't set the enumeration. Also changing the namespace
doesn't change the enumeration.

I think this can probably be classified as a bug in tablegen. It
shouldn't be generating enumerated opcode values with the same values as
built in opcodes.
-bw
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Sep 18, 2008, at 4:04 PM, Villmow, Micah wrote:
> I am using lowering instructions and using custom opcodes that I can  
> more easily directly map to my backend. These opcodes are then used  
> to emit a custom set of instructions into the MachineBasicBlock.  
> I’ve been able to get one to work correctly, however, I’ve ran into  
> an issue where my second one is being confused as a FRAMEADDR opcode  
> instead of my opcode.
Make sure to use DAG.getTargetNode() with custom opcodes.  "target"  
nodes are encoded with an implicit delta added to their enum value.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080919/6530bb94/attachment.html>

________________________________

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Chris Lattner
Sent: Friday, September 19, 2008 10:49 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Custom Opcodes versus built-in opcodes

 

 

On Sep 18, 2008, at 4:04 PM, Villmow, Micah wrote:





I am using lowering instructions and using custom opcodes that I can
more easily directly map to my backend. These opcodes are then used to
emit a custom set of instructions into the MachineBasicBlock. I've been
able to get one to work correctly, however, I've ran into an issue where
my second one is being confused as a FRAMEADDR opcode instead of my
opcode.

 

Make sure to use DAG.getTargetNode() with custom opcodes.  "target"
nodes are encoded with an implicit delta added to their enum value.

 

Is this documented anywhere that getTargetNode is the preferred method
to use in a Custom Lowering function? Even the other backends use
getNode in their lowering functions with custom opcodes.

This is from SparcISelLowering.cpp

CompareFlag = DAG.getNode(SPISD::CMPFCC, MVT::Flag, LHS, RHS);

    if (SPCC == ~0U) SPCC = FPCondCCodeToFCC(CC);

    Opc = SPISD::BRFCC;

  }

  return DAG.getNode(Opc, MVT::Other, Chain, Dest,

                     DAG.getConstant(SPCC, MVT::i32), CompareFlag);

 

Micah

 

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