[LLVMdev] weird issue with mem2reg, still

Chris Lattner sabre at nondot.org
Wed Jun 23 17:00:02 PDT 2004 

On Wed, 23 Jun 2004, Patrick Meredith wrote:

>  void MetaSplit::handleProgramUses(Value *V){
>   if(!isa<BasicBlock>(V))
>    programValues.insert(V);
>   if(User *U = dyn_cast<User>(V)){
>    User::op_iterator OB = U->op_begin(), OE = U->op_end();
>    for(; OB != OE; ++OB){
>     if(CallInst *CI = dyn_cast<CallInst>(*OB)){
>       Function *F = CI->getCalledFunction();
>       if(F == ii || F == fi || F == vi || F == di || F == ci || F == si){
>        std::cerr << "This Call: " << *CI << std::endl;
>        std::cerr << "\tNum Operands: " << CI->getNumOperands() << std::endl;
>        handleGeneratorUses(CI->getOperand(1));
>       }
>     }
>     else if(!(*programValues.find(*OB))){
>      handleProgramUses(*OB);
>     }
>    }
>   }
>  }
>
> pmeredit|zion|/localhome/pmeredit/llvm/projects/MetaSplit/lib/MetaSplit|[189
> ]% opt -load ../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc >
> m2r.bc
> This Call:      %tmp.10 = call int %_Z1Ii( int %i.0 )           ; <int>
> [#uses=1]
>
>         Num Operands: 2
> Segmentation fault (core dumped)

Okay, this code looks fine.  Are you absolutely positive that it's
segfaulting in getOperand *before* control gets into your
handleGeneratorUses function?

>
> bugpoint...
> *** Attempting to perform final cleanups: This Call:    %tmp.13 = call int
> %_Z1Ii( )            ; <int> [#uses=1]
>
>         Num Operands: 1
> bugpoint: /home/vadve/lattner/cvs/llvm/include/llvm/User.h:35: llvm::Value*
> llvm::User::getOperand(unsigned int): Assertion `i < Operands.size() &&
> "getOperand() out of range!"' failed.
>
> Now this is really strange, because it seems that the bugpoint function
> differs from what is there on the normal run.  Also, a call to int %_Z1Ii
> must ALWAYS have an interger argument (it's prototype is
> int(int)), which aparently is no longer there (in the bugpoint version).

That is odd.  Can you send me (offline) your .so file and .bc file and
I'll try to reproduce this?  bugpoint should never coredump or fail and
assertion like this (you've found a bugpoing bug).

> By far the best thing is I inserted an if that was if(numOperands > 1)
> perform get operand call and this assert still happens.

Question: are you modifying the code at all?  In particular, are you
inserting calls to these functions?

-Chris

> ----- Original Message -----
> From: "Chris Lattner" <sabre at nondot.org>
> To: <llvmdev at cs.uiuc.edu>
> Sent: Wednesday, June 23, 2004 4:46 PM
> Subject: Re: [LLVMdev] weird issue with mem2reg, still
>
>
> > On Wed, 23 Jun 2004, Patrick Meredith wrote:
> >
> > > Somehow it fails with operand out of bounds when the number of operands
> > > is 2 and I am asking for the second operand. Second meaning operand 1.
> >
> > Okay, so you have something like this:
> >
> >   if (CallInst *CI = dyn_cast<CallInst>(...)) {
> >
> >      ... = CI->getOperand(1);
> >   }
> >
> > Can you send in this snippet of code, the assertion, and the results of:
> >   std::cerr << "TheCall: " << *CI;
> >
> > executed right before the getOperand call that is failing?
> >
> > -Chris
> >
> >
> > > ----- Original Message -----
> > > From: "Chris Lattner" <sabre at nondot.org>
> > > To: <llvmdev at cs.uiuc.edu>
> > > Sent: Wednesday, June 23, 2004 4:24 PM
> > > Subject: Re: [LLVMdev] weird issue with mem2reg, should have guessed
> > >
> > >
> > > > On Wed, 23 Jun 2004, Patrick Meredith wrote:
> > > >
> > > > > What's different about code that's been mem2reg'd from straight
> front
> > > end
> > > > > code, or anything that mem2reg hasn't been run on?  PHINODES!
> > > >
> > > > Yup, front-ends generally don't produce SSA form. :)
> > > >
> > > > > It appears to be crashing when I try to cast a Value* that's really
> a
> > > > > BB* (from the PHInode operands) to a User*, insteresting since I am
> > > > > dyn_casting.  I just caught this on cerr though (printing out what
> the
> > > > > Value* was each time).
> > > >
> > > > Yeah, you shouldn't do that. :)  Also, you should use the 'cast'
> template
> > > > instead of the dyn_cast template unless you are prepared to handle the
> > > > null return value.  Use 'cast' when you _know_ that something is a
> > > > particular type.  This will give you a nice assertion failure instead
> of a
> > > > segfault when you deref the null pointer :)
> > > >
> > > > > Let me check bugpoint.
> > > >
> > > > Cool, post the testcase it produces.  Hopefully it will be small :)
> > > >
> > > > -Chris
> > > >
> > > > > ----- Original Message -----
> > > > > From: "Misha Brukman" <brukman at uiuc.edu>
> > > > > To: <llvmdev at cs.uiuc.edu>
> > > > > Sent: Wednesday, June 23, 2004 3:56 PM
> > > > > Subject: Re: [LLVMdev] weird issue with mem2reg
> > > > >
> > > > >
> > > > > > On Wed, Jun 23, 2004 at 03:50:09PM -0500, Patrick Meredith wrote:
> > > > > > > MetaSplit is an anlysis I just finished writing.  It doesn't
> alter
> > > > > > > anything, all it does is build a set of "program instructions".
> For
> > > > > > > some reason even though if I run it with any other combination
> of
> > > > > > > passes I've found, anytime I run it with mem2reg I get a seg
> fault
> > > in
> > > > > > > dyn_cast!  Here's output:
> > > > > >
> > > > > > Since the crash is after your code is entered, the problem is
> probably
> > > > > > not in mem2reg, but in your pass.  To see if that's the case, you
> can
> > > do
> > > > > > this:
> > > > > >
> > > > > > % opt -mem2reg < orig.bc > m2r.bc
> > > > > > % opt -load=... -metasplit < m2r.bc > output.bc
> > > > > >
> > > > > > And see if it crashes in mem2reg or in your pass.  To narrow your
> > > > > > testcase down further, we recommend the use of bugpoint, the
> automatic
> > > > > > test case reducer:
> > > > > >
> > > > > >   http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html
> > > > > >
> > > > > > In this case, this should work:
> > > > > >
> > > > > > % bugpoint -load=... -mem2reg -metasplit orig.bc
> > > > > >
> > > > > > --
> > > > > > Misha Brukman :: http://misha.brukman.net ::
> http://llvm.cs.uiuc.edu
> > > > > >
> > > > > > _______________________________________________
> > > > > > LLVM Developers mailing list
> > > > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > > >
> > > > > _______________________________________________
> > > > > LLVM Developers mailing list
> > > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > > > >
> > > >
> > > > -Chris
> > > >
> > > > --
> > > > http://llvm.cs.uiuc.edu/
> > > > http://www.nondot.org/~sabre/Projects/
> > > >
> > > > _______________________________________________
> > > > LLVM Developers mailing list
> > > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> >
> > -Chris
> >
> > --
> > http://llvm.cs.uiuc.edu/
> > http://www.nondot.org/~sabre/Projects/
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/

More information about the llvm-dev mailing list