search for: visitadd

...ndex:i64<0>, Constant:i64<56> Creating new node: t121: i64 = or FrameIndex:i64<0>, Constant:i64<56> ... into: t121: i64 = or FrameIndex:i64<0>, Constant:i64<56> This caused problem if frame pointer points 0x60000038 at run time. I checked DAGCombiner::visitADD. It folds ADD to OR by following code without considering about FrameIndex. This haveNoCommonBitsSet says it's safe since FrameIndex(0) is 0. // fold (a+b) -> (a|b) iff a and b share no bits. if ((!LegalOperations || TLI.isOperationLegal(ISD::OR, VT)) && DAG....

...question is the following: http://lists.llvm.org/pipermail/llvm-dev/2015-January/080666.html Perhaps these operations are cheaper than I think and such caching is not needed? Alternatively they could be put behind -O3 i.e. the ExpensiveCombines variable Sanjay pointed out. > 2. InstCombiner::visitAdd only calls into ValueTracking for the > unsigned case, i.e. computeOverflowForUnsignedAdd. There are no > computeOverflowFor*Sub functions that InstCombiner::visitSub even > could make use of. Instead, InstCombiner has its own > WillNotOverflow{S,UnS}igned{Add,Sub} functions. The re...

...omputeKnownBits() has a case for ISD::CTLZ, and it seems to figure out that the high bits of t17 are zero, as expected. t17 is guaranteed to have a value between 48 and 64, so there could not be any overflow here, even though I am not sure if that's the problem or not... Should DAGCombiner::visitADD() handle this, or perhaps visitTRUNCATE()? Thanks for any help, Jonas

...was whittled down from a fixed point math test by bugpoint, and further simplified by hand.    The problem did not occur in 2.8. > (Removing the trivial branch makes the problem go away.) > > I'm not sure where to begin debugging it, so any pointers would be appreciated. DAGCombiner::visitADDE looks suspicious to me... specifically, the way ReplaceAllUsesOfValueWith is used. -Eli

...e*'s -> vregs: this is what the instruction > selector is about. > > I recommend taking a look at the getReg(*) methods in the X86 instruction > selector. The basic code generation stage for an add, boiled down to its > simplest form, basically looks like this: > > void visitAdd(BinaryOperator &B) { > unsigned Op0Reg = getReg(B.getOperand(0)); > unsigned Op1Reg = getReg(B.getOperand(1)); > unsigned DestReg = getReg(B); > > unsigned Opcode = (get the opcode for the size of the add); > BuildMI(<where>, Opcode, 2, DestReg).addReg(Op0Reg)....

...operands, if target does not allow > that. The ultimate solution is to use a pattern matching instruction selector (which we are working on). In the meantime, depending on how RISCy your target is, it's pretty easy to get reasonable code with few special cases. Usually this is enough: ... visitAdd(Instruction &I) { if (ConstantInt *C = dyn_cast<Constant>(I.getOperand(1))) { // handle add r, i } else { // handle general 'add r,r' case. } } In particular, I *strongly* recommend getting a working code generator first, even if it creates mind boggling ugly code....

In both LLVM 2.9 and the current svn head, I get the following error when running llc % llc < fxp2.ll LLVM ERROR: Cannot select: 0xa5302b0: glue = carry_false [ID=7] on this code: target triple = "i386-pc-linux-gnu" define i32 @fxpadd(i32 %cl) { entry: %0 = zext i32 %cl to i128 %1 = zext i32 %cl to i128 %2 = add i128 %1, %0 br label %L1001510 L1001510:

...ntext to hold the mapping of Value*'s -> vregs: this is what the instruction selector is about. I recommend taking a look at the getReg(*) methods in the X86 instruction selector. The basic code generation stage for an add, boiled down to its simplest form, basically looks like this: void visitAdd(BinaryOperator &B) { unsigned Op0Reg = getReg(B.getOperand(0)); unsigned Op1Reg = getReg(B.getOperand(1)); unsigned DestReg = getReg(B); unsigned Opcode = (get the opcode for the size of the add); BuildMI(<where>, Opcode, 2, DestReg).addReg(Op0Reg).addReg(Op1Reg); } The nice t...

Ok, I'm now trying to write instruction selector and have some questions 1. The MachineInstrBuilder has methods to add register operand and immediate operand. However, what would be really nice is a method to add Value*. So, I would write: BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1)); and depending on whether the passed Value* is contant or instruction, the add

...s Lattner wrote: > The ultimate solution is to use a pattern matching instruction selector > (which we are working on). In the meantime, depending on how RISCy your > target is, it's pretty easy to get reasonable code with few special cases. > Usually this is enough: > > ... visitAdd(Instruction &I) { > > if (ConstantInt *C = dyn_cast<Constant>(I.getOperand(1))) { > // handle add r, i > } else { > // handle general 'add r,r' case. > } > } > > In particular, I *strongly* recommend getting a working code generator > fi...

...cadc in llvm::Value::getType (this=0x0) at /work/aditya/llvm-2.2/include/llvm/Value.h:87 #3 0x08637b52 in (anonymous namespace)::Verifier::visitBinaryOperator (this=0x8794f18, B=@0x87994a8) at Verifier.cpp:905 #4 0x0863d81e in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visitAdd (this=0x8794f18, I=@0x87994a8) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:107 #5 0x0863de16 in llvm::InstVisitor<(anonymous namespace)::Verifier, void>::visit (this=0x8794f18, I=@0x87994a8) at /work/aditya/llvm-2.2/include/llvm/Instruction.def:107 #6 0x0863e229 in llvm::In...