search for: setcondcodeact

...n that indicates how instruction selection should /// > deal with the condition code. uint64_t > CondCodeActions[ISD::SETCC_INVALID]; > > What I suggest is the following: > Change the definition of CondCodeAction to: > uint64_t CondCodeActions[ISD::SETCC_INVALID][2]; > > setCondCodeAction then becomes: > void setCondCodeAction(ISD::CondCode CC, MVT VT, > LegalizeAction Action) { > assert(VT < MVT::LAST_VALUETYPE && > (unsigned)CC < array_lengthof(CondCodeActions) && > "Table isn't big...

...CondCode) keep a /// LegalizeAction that indicates how instruction selection should /// deal with the condition code. uint64_t CondCodeActions[ISD::SETCC_INVALID]; What I suggest is the following: Change the definition of CondCodeAction to: uint64_t CondCodeActions[ISD::SETCC_INVALID][2]; setCondCodeAction then becomes: void setCondCodeAction(ISD::CondCode CC, MVT VT, LegalizeAction Action) { assert(VT < MVT::LAST_VALUETYPE && (unsigned)CC < array_lengthof(CondCodeActions) && "Table isn't big enough!"); Cond...

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)

...tion should /// > > deal with the condition code. uint64_t > > CondCodeActions[ISD::SETCC_INVALID]; > > > > What I suggest is the following: > > Change the definition of CondCodeAction to: > > uint64_t CondCodeActions[ISD::SETCC_INVALID][2]; > > > > setCondCodeAction then becomes: > > void setCondCodeAction(ISD::CondCode CC, MVT VT, > > LegalizeAction Action) { > > assert(VT < MVT::LAST_VALUETYPE && > > (unsigned)CC < array_lengthof(CondCodeActions) && > >...

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 unorder...

...explains, "// Don't care operations: undefined if the input is a nan.". > > To support the unordered comparisons, if your FPU has only ordered > comparisons, then you might need to do the underlying comparison, and a NaN > check, and then OR the results. I think that using setCondCodeAction will > cause the expansions for the hardware-unsupported variants to happen for > you. > > -Hal > Thanks Hal for the guidance ! -Vivek > > so do I need to use > getSetCCInverse() ? Also when I look at the code of > TargetLowering::softenSetCCOperands I see that for...

...s converted to ule, > do I convert all ule into olt and swap? The existing legalization infrastructure for condition codes is in SelectionDAGLegalize::LegalizeSetCCCondCode. If this isn't flexible enough, you might need to modify it a bit. You should be able to just do something like "setCondCodeAction(ISD::SETOGT, MVT::f64, Expand);" for the unsupported comparisons, and let Legalize should take care of the rest. Oh, and it looks like there's a legitimate bug in DAGCombiner::visitXOR: it needs to check whether condition codes are legal before transforming them. -Eli

Eli, Using the variables from the original IR, assuming tmp == tmp1 and assume the value is not nan ogt(tmp, tmp1) is !isnan(tmp) && !isnan(tmp1) && tmp > tmp1, or false ule(tmp, tmp1) is isnan(tmp) || isnan(tmp1) || tmp <= tmp1, or true So, this is invalid, or am I misunderstanding what ogt and ule stand for? Assuming this is valid, why convert comparison instructions

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 is available: fcmp.un --> true if one of the operand is NaN fcmp.lt --> ordered less than, if any input NaN then return false fcmp.eq --> ordered equal, if any input NaN