search for: condcod

...return false When FPU is not present I need to generate a library call, so I have added following code in LowerBR_CC function in XXXISelLowering.cpp const XXXSubtarget &STI = static_cast<const XXXSubtarget&> (DAG.getSubtarget()); XXXCC::CondCodes TCC; getFPCCtoXXCC(CC,TCC); TargetCC = DAG.getConstant(TCC, dl, MVT::i8); if (STI.useHardFloat()) { // if fcmp instruction is available use it SDValue Flag = DAG.getNode(XXXISD::FCMP, dl, MVT::Glue, LHS, RHS, TargetCC); return DAG.getNode(XXXISD::BR_CC, dl, Op.g...

...sent I need to generate a library call, > > so I have added following code in LowerBR_CC function in > XXXISelLowering.cpp > > const XXXSubtarget &STI = static_cast<const XXXSubtarget&> > (DAG.getSubtarget()); > XXXCC::CondCodes TCC; > getFPCCtoXXCC(CC,TCC); > TargetCC = DAG.getConstant(TCC, dl, MVT::i8); > if (STI.useHardFloat()) { > // if fcmp instruction is available use it > SDValue Flag = DAG.getNode(XXXISD::FCMP, dl, MVT::Glue, LHS, RHS, > TargetCC); > return...

On 03/14/2017 07:16 AM, vivek pandya wrote: > Hello Hal, > setCondCodeAction(expand) for un ordered comparison generates > semantically wrong code for me for example SETUNE gets converted to > SETOE that causes infinite loops. Can you please explain what is happening? It sounds like a bug we should fix. > > What is ideal place where I can convert uno...

I'm getting this: /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In member function `void llvm::SelectionDAGLowering::visitSetCC(llvm::User&, llvm::ISD::CondCode, llvm::ISD::CondCode, llvm::ISD::CondCode)': /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107: error: ` UnsafeFPMath' undeclared (first use this function) /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107: error: (Each undeclared...

I'm trying to understand why this assertion is here. LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy < sizeof(CondCodeActions[0])*4 && "Table isn't big enough!"); LegalizeAction Action = (LegalizeActi...

On Thu, 26 Jul 2012 21:15:35 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Well, I found out the reason why this assert is here, and this is > problematic. > > CondCodeActions only supports up to 32 different value types. Since > we are past 32, what LLVM has is broken. > > Currently the 4 different Legalize states are stored in successive > bits and packed into a uin64_t, see TargetLowering.h. /// > CondCodeActions - For each condition code (ISD:...

Well, I found out the reason why this assert is here, and this is problematic. CondCodeActions only supports up to 32 different value types. Since we are past 32, what LLVM has is broken. Currently the 4 different Legalize states are stored in successive bits and packed into a uin64_t, see TargetLowering.h. /// CondCodeActions - For each condition code (ISD::CondCode) keep a /// L...

...is broken. Either patch is fine, just need approval from someone to submit. Micah > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Thursday, July 26, 2012 2:39 PM > To: Villmow, Micah > Cc: Developers Mailing List > Subject: Re: [LLVMdev] RFC: CondCodeActions refactor (was RE: Why is > this assertion here?) > > On Thu, 26 Jul 2012 21:15:35 +0000 > "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > > Well, I found out the reason why this assert is here, and this is > > problematic. > > > &...

> * We have opposite condition codes in our FP comparisons. No, Evzen is correct. The condcode is used to test the libcall result against zero and EABI libcalls return 1 in case of "true" result of the comparison, thus we have to invert the condcode agains the default value. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State Uni...

Hi, I notice that the following recent addition X86::CondCode X86::getCondFromBranch(const MachineInstr &MI) { switch (MI.getOpcode()) { default: return X86::COND_INVALID; case X86::JCC_1: return static_cast<X86::CondCode>( MI.getOperand(MI.getDesc().getNumOperands() - 1).getImm()); } } returns an invalid condition for JCC_2 an...

I wrote that loop. :-) So now the differences between this patch and the one I had been sitting on are: * We have opposite condition codes in our FP comparisons. * This patch has integer division, which seems like a good thing, but wasn't needed for my A9 target. Are you sure about the comparisons? deep On Tue, Sep 28, 2010 at 9:11 AM, Evzen Muller <evzen.muller at arm.com> wrote:

Hi all, When trying to generate a VFCmp instruction when UnsafeFPMath is set to true I get an assert "Unexpected CondCode" on my x86 system. This also happens with UnsafeFPMath set to false and using an unordered compare. Could someone look into this? While I'm at it, is there any reason why only the most significant bit of the return value of VFCmp is defined (according to the documentation)? Both AltiV...

Vladimir Prus wrote: > > I'm getting this: > > /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: > In > member function `void > llvm::SelectionDAGLowering::visitSetCC(llvm::User&, > llvm::ISD::CondCode, llvm::ISD::CondCode, llvm::ISD::CondCode)': > /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107: > error: ` > UnsafeFPMath' undeclared (first use this function) Forget it, I've pressed "Send" in wrong window. See the llvmbugs list for...

...= DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(1), DAG.getConstant(0, MVT::i32)); SDOperand RHSH = DAG.getNode(ISD::EXTRACT_ELEMENT, MVT::i32, N->getOperand(1), DAG.getConstant(1, MVT::i32)); // Expand SDOperand Lo = DAG.getNode(N->getOpcode(), MVT::i32, LHSL, RHSL); ISD::CondCode CarryCC = (N->getOpcode() == ISD::ADD) ? ISD::SETULT : ISD::SETUGT; SDOperand Carry = DAG.getSetCC(MVT::i32, Lo, LHSL, CarryCC); SDOperand Hi = DAG.getNode(N->getOpcode(), MVT::i32, LHSH, Carry); Hi = DAG.getNode(N->getOpcode(), MVT::i32, Hi, RHSH); // Merge the pieces return DAG.getNod...

On Tue, Sep 28, 2010 at 9:24 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> * We have opposite condition codes in our FP comparisons. > No, Evzen is correct. The condcode is used to test the libcall result > against zero and EABI libcalls return 1 in case of "true" result of > the comparison, > thus we have to invert the condcode agains the default value. I guess I never saw a float cmp libcall in my testing, which makes sense for the platforms...

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Have you filed a bug? > > While I’m at it, is there any reason why only the most significant > bit of the return value of VFCmp is defined (a...

Hi, That's what the DecoderMethod is for. Similarly ParserMatchClass for the asm parser and PrintMethod for the asm printer: def CondCodeOperand : AsmOperandClass { let Name = "CondCode"; } def pred : PredicateOperand<OtherVT, (ops i32imm, i32imm), (ops (i32 14), (i32 zero_reg))> { let PrintMethod = "printPredicateOperand"; let ParserMatchClass = CondCodeOperand; l...

My target doesn't support 64 bit arithmetic, so I'd like to supply definitions for adde/addc. The problem is I can't seem to figure out the magic. Here's an example of what I need to generate: # two i64s in r5/r6 and r7/r8 # result in r1/r2, carry in r3 # adde add r2, r6, r8 cmpltu r3, r2, r6 # compute carry # addc add r1, r5, r7 add r1, zero, r3 Is this

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Please provide a testcase. > > While I’m at it, is there any reason why only the most significant > bit of the return value of VFCmp is defin...

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? > > While I’m at it, is there any reason why only the most significant > bit of the return value of VFCmp is defined (according to the > d...