search for: visitxor

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

...bits (it still must be extended to OR and AND instructions). Any comments and critics are appreciated. Basically, I try to identify a chain of XOR instructions and fold it. The below image illustrate this: [image: XORChain.png] In order to do that I am adding an additional function call to "visitXor()" in Instruction Combining. My Optimization function is attached as a patch file. (the diff was made using the 2.9 release version of llvm). Thanks Daniel Nicacio -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/at...

...gt;> SDNode *TheXor = N1.getNode(); >> SDValue Op0 = TheXor->getOperand(0); >> SDValue Op1 = TheXor->getOperand(1); >> if (Op0.getOpcode() == Op1.getOpcode()) { >> // Avoid missing important xor optimizations. >> SDValue Tmp = visitXOR(TheXor); >> if (Tmp.getNode()&& Tmp.getNode() != TheXor) { >> DEBUG(dbgs()<< "\nReplacing.8 "; >> TheXor->dump(&DAG); >> dbgs()<< "\nWith: "; >> Tmp.getNode()...

2011/7/26 Daniel Nicácio <dnicacios at gmail.com>: > > I also would like to see why the "XOR  A,  -1" is not turned into a NOT, any > Probably because NOT (like NEG) doesn't exist :) <http://llvm.org/docs/LangRef.html#instref> I assume the decision was made that it wasn't worth adding the extra unary instructions when they can easily be handled in codegen

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

On Monday, July 30, 2012 12:16 AM, Cameron McInally wrote: > Hey Andy, > > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > Parts of my patch did make it into trunk about a year after, but others > did not. > > At that time, my solution was to add a binary operator to the IRBuilder, > since LCS fits in nicely with the other shift operators. But,

...hasOneUse() && N1.getOpcode() == ISD::XOR) { SDNode *TheXor = N1.getNode(); SDValue Op0 = TheXor->getOperand(0); SDValue Op1 = TheXor->getOperand(1); if (Op0.getOpcode() == Op1.getOpcode()) { // Avoid missing important xor optimizations. SDValue Tmp = visitXOR(TheXor); if (Tmp.getNode() && Tmp.getNode() != TheXor) { DEBUG(dbgs() << "\nReplacing.8 "; TheXor->dump(&DAG); dbgs() << "\nWith: "; Tmp.getNode()->dump(&DAG); dbgs() &l...

...stCombine/InstCombine.h =================================================================== --- lib/Transforms/InstCombine/InstCombine.h (revision 161045) +++ lib/Transforms/InstCombine/InstCombine.h (working copy) @@ -134,6 +134,7 @@ Instruction *visitOr (BinaryOperator &I); Instruction *visitXor(BinaryOperator &I); Instruction *visitShl(BinaryOperator &I); + Instruction *visitCShl(BinaryOperator &I); Instruction *visitAShr(BinaryOperator &I); Instruction *visitLShr(BinaryOperator &I); Instruction *commonShiftTransforms(BinaryOperator &I); Index: lib/Tra...

...asserts happen because a logic operation is attempted between a vector and a scalar (which is not present in the original code, but created by InstCombine). It's caused by revision 73431. I was able to fix it by changing the following (identical) lines in InstCombiner::visitAnd, visitOr and visitXor: if (SimplifyDemandedInstructionBits(I)) return &I; Into: if (!isa<VectorType>(I.getType()) && SimplifyDemandedInstructionBits(I)) return &I; Apparently SimplifyDemandedInstructionBits doesn't work correctly with vector operands, sometimes rep...

...1.getOpcode() == ISD::XOR) { > SDNode *TheXor = N1.getNode(); > SDValue Op0 = TheXor->getOperand(0); > SDValue Op1 = TheXor->getOperand(1); > if (Op0.getOpcode() == Op1.getOpcode()) { > // Avoid missing important xor optimizations. > SDValue Tmp = visitXOR(TheXor); > if (Tmp.getNode() && Tmp.getNode() != TheXor) { > DEBUG(dbgs() << "\nReplacing.8 "; > TheXor->dump(&DAG); > dbgs() << "\nWith: "; > Tmp.getNode()->dump(&DAG); >...

After a few more tests, I found out that if we set -unroll-threshold to a value large enough, and run "opt -std-compile-opts" or "opt -O3" 3 times, the unroll will be able to unroll the original loop 32 times, and when you have it unrolled for at least 32 times a optimization is triggered, folding it to a single "%xor.3.3.1 = xor i32 %tmp6, -1" (dont know why it does

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 defined comparison >> >> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;

On 29 Sep 2010, at 06:25, Heikki Kultala wrote: > Our architecture has 1-bit boolean predicate registers. > > I've defined comparison > > > def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>; > > > > > But then I end up having the following bug: > >

I am not entirely sure this is safe. Transforming this to an fsub could change the value stored on platforms that implement negates using arithmetic instead of with bitmath (such as ours) and either canonicalize NaNs or don’t support denormals. This is actually important because this kind of bitmath on floats is very commonly used as part of algorithms for complex math functions that need to get