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/
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)
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).
By far the best thing is I inserted an if that was if(numOperands > 1)
perform get operand call and this assert still happens.
----- 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
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/