search for: markconst

Hi Anton, in a solution without CAZ, isNullValue can just return true when it sees the special "this ConstantArray is all zero" flag. So all the places that now look for CAZ can just use isNullValue instead and there need be no performance loss. That said, CAZ is more "in your force" so less likely to be forgotten about. Another interesting possibility is to handle more than

...sConstant()) + L = V1State.getConstant(); + Constant *R = UndefValue::get(I.getOperand(0)->getType()); + if (V2State.isConstant()) + R = V2State.getConstant(); + Constant *C = ConstantExpr::get(I.getOpcode(), L, R); + if (isa<UndefValue>(C)) + return; + return markConstant(IV, &I, C); + } // Otherwise, one of our operands is overdefined. Try to produce something // better than overdefined with some tricks. Also, did you mean to make the lattice as: digraph G { Unknown -> Undef Undef -> Constant1 Undef -> Constant2 Undef -> Con...

...an invalid location (in this case, off the end of the array) > into an undef value. If you wanted to tackle this, it should be > straight-forward and would be a worthwhile addition to the LLVM > optimizer. In SCCPSolver::visitGetElementPtrInst, it would fall through to the final markConstant call at the end of the function. Someone should be doing a check with indexValid to see if instead it should be marking as undefined. I can try to produce such a patch. >> I thought this might be because the optimizer is being conservative >> about correctness, but that the lattice...

On Wed, 10 May 2006, Nick Lewycky wrote: >> Then just run the SCCP pass, and check to see if any operands satisfy >> the predicate "isa<UndefValue>(V)". LLVM explicitly represents >> undefined values. > > I have a case where it doesn't, but perhaps the SCCP pass isn't to blame: > > extern void write_char(int); > > const char foo[4] =

...Constant(); > + Constant *R = UndefValue::get(I.getOperand(0)->getType()); > + if (V2State.isConstant()) > + R = V2State.getConstant(); > + Constant *C = ConstantExpr::get(I.getOpcode(), L, R); > + if (isa<UndefValue>(C)) > + return; > + return markConstant(IV, &I, C); > + } > > // Otherwise, one of our operands is overdefined. Try to produce > something > // better than overdefined with some tricks. > > > > > Also, did you mean to make the lattice as: > > digraph G { > Unknown -> Undef >...

Chris Lattner wrote: > On Tue, 9 May 2006, Nick Lewycky wrote: > >>> You could do that, but SCCPSolver isn't really useful to mainline LLVM >>> for anything other than SCCP and IPSCCP, so we don't need it in a public >>> header. Out of curiosity, what are you looking to use the latice values >>> for? Why not just run SCCP and then look at the

...nstant *R = UndefValue::get(I.getOperand(0)->getType()); >> + if (V2State.isConstant()) >> + R = V2State.getConstant(); >> + Constant *C = ConstantExpr::get(I.getOpcode(), L, R); >> + if (isa<UndefValue>(C)) >> + return; >> + return markConstant(IV, &I, C); >> + } >> >> // Otherwise, one of our operands is overdefined. Try to produce >> something >> // better than overdefined with some tricks. >> >> >> >> >> Also, did you mean to make the lattice as: >> >&g...

On Fri, Dec 30, 2016 at 9:27 AM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi. > I'm sending this email to -dev as this may be of interest of > many/people may have opinions/want to try the change before it goes in > to report problems. > I've been recently working on a patch to integrate `undef` in the SCCP > solver, in the hope of fixing

Hi. I'm sending this email to -dev as this may be of interest of many/people may have opinions/want to try the change before it goes in to report problems. I've been recently working on a patch to integrate `undef` in the SCCP solver, in the hope of fixing a tail of latent bugs in SCCP which remained uncovered for many years. I think this is a decent time to propose, so that it can