similar to: Help understanding and lowering LLVM IDS conditional codes correctly

On Thu, Mar 9, 2017 at 9:35 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > On 02/25/2017 03:06 AM, vivek pandya via llvm-dev wrote: > > Note: Question is written after describing what I have coded. > > Hello LLVMDevs, > > I am trying to impliment floating point comparsion for an architecture > which > supports following type of floating point comparision if FPU

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 unordered comparison to un

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)

Hi Dan, If you set the node's action to "Custom", you should be able to interfere in the type legalisation phase (before it gets promoted to a 64-bit MUL) by overriding the "ReplaceNodeResults" function. You could either expand it to a different libcall directly there, or replace it with a target-specific node (say XXXISD::MUL32) which claims to take i64 types but you

Thanks for the information, allow maybe I can re-phrase the question or issue. Assume 64-bit register types, but integer is 32-bit. Already have table generation of the 64-bit operation descriptions. How about this modified approach? Before type-legalization, I'd really like to move all MUL I64 to a subroutine call of my own choice. This would be a form of customization, but I want this

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 >

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 /// LegalizeAction

Yeah just the ordering are the real difference. Also, I use shifts and masks instead of conditionals and modules. My patch is attached. For me either patch is fine, but what LLVM has now 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

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 = (LegalizeAction)

Bill Wendling wrote: > On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > >> Bill Wendling wrote: >>> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >>> >>>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>>> >>>>> Our architecture has 1-bit boolean predicate registers. >>>>> >>>>> I've

> * 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

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 and JCC_4 conditional opcodes. What is

Thanks Tom. I really appreciate your insight. I'm able to use the customize to get the 64-bit to go to a subroutine and for the 32-bit, I am generate XXXISD::MUL32. I'm not sure then what you mean about "overriding" the ReplaceNodeResults. For ReplaceNodeResults, I'm doing: SDValue Res = LowerOperation(SDValue(N, 0), DAG); for (unsigned I = 0, E =

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

Richard Pennington wrote: > 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 #

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:

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

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";

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

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