[LLVMdev] Custom Opcodes versus built-in opcodes

Villmow, Micah Micah.Villmow at amd.com
Thu Sep 18 16:04:05 PDT 2008


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>


More information about the llvm-dev mailing list