IRC: Discussion About Upgrades To Bugzilla

I thought this conversation was worth saving. DannyB who did wonderful
things with GCC's use of bugzilla has offered the same capability to
LLVM.

Thanks, Danny!

<DannyB> sabre: BTW, if you need any of the bugzilla fun i have implemented for gcc, let me know
[22:47] <sabre> Cool, what kinds of things do you have?
[22:47] <DannyB> Besides the triplet stuff, i changed some of the workflow, added some email related features (incoming email handling, changed outgoing email format, made it not send out "useless" emails like keyword-only changes), etc
[22:48] <DannyB> Incoming email handling and comment appending by email now handles attachments properly
[22:48] <DannyB> all kinds of stuff
[22:48] <sabre> Incoming email handling is the thing I would be most interested in
[22:48] <sabre> It would be really nice to be able to respond to a bugzilla sent mail and have it appended to the bug
[22:48] <DannyB> That's easy
[22:48] <sabre> Is it built in?
[22:48] <sabre> :slight_smile:
[22:49] <DannyB> define "builtin"
[22:49] <sabre> I wouldn't be surprised if there was just a setting that needed to be enabled. :slight_smile:
[22:49] <DannyB> No, because you have to set up incoming email aliases
[22:49] <DannyB> So that the mail gets passed off to the script
[22:49] <sabre> Ok
[22:50] <sabre> well easy is good. Are there dox for doing it, or do you have local hacks in the gcc bugz?
[22:50] <DannyB> I also added support so that we know who made the change, and it gets spam-protected and placed in the from
[22:50] <sabre> You've been busy!
[22:50] <DannyB> So you see email from "dan at dberlin dot org" <gcc-bugzilla@gcc.gnu.org>
[22:50] <DannyB> instead of "Bugzilla daemon"
[22:50] <sabre> That is nice
[22:51] <DannyB> I'll email you the incoming comment handling script. it's rather small, and easy to deal with.
[22:51] <sabre> Hrm, yeah, how can I get some of this stuff from you?
[22:51] <sabre> sounds great!
[22:51] <DannyB> or you can check it out from the gcc CVS repo
[22:51] <DannyB> it's in wwwdocs/bugzilla/contrib
[22:51] <DannyB> bugzilla_email_append.pl and BugzillaEmailpl
[22:51] <DannyB> s/pl/.pm/
[22:51] <sabre> brg and misha are the bugzilla guys
[22:52] <sabre> I haven't done much at all with it, but we will definitely take a look
[22:52] <DannyB> Happy to help in any way i can
[22:52] <sabre> Yeah, just responding to the emails would make things so much faster
[22:52] Action: sabre is worklist driven from his inbox
[22:52] <DannyB> I'm responsible for having moved gcc from GNATS to bugzilla, and now for maintaining gcc bugzilla :slight_smile:
[22:52] <DannyB> I also have a nice email interface to bugzilla
[22:52] <sabre> Yeah, I remember the transition
[22:52] <DannyB> so you can get the results of bug queries by email
[22:53] <sabre> Hrm, I don't mind using the "gui" for most things. It's just the conversations/feedback on bugs that drives me (more) nuts
[22:53] <DannyB> okay, well, all you have to do is set the reply-to on the emails sent out to be the email address of the incoming handler.
[22:54] <DannyB> and make sure people don't quote the entire damn email in a response :slight_smile:
[22:54] <sabre> heh
[22:54] <sabre> That might be the difficult issue :slight_smile:
[22:54] <DannyB> (otherwise, it'll appear in the comment)
[22:54] <sabre> understood
[22:54] <DannyB> Well, there are various ways to take care of it from a script perspective
[22:54] <DannyB> you could put BUGZILLA:> in front of every line, then ignore every response line with it
[22:54] <DannyB> or something
[22:54] <sabre> That could work
[22:55] Action: sabre ponders
[22:55] <sabre> brg: ping
[22:55] <DannyB> there are a billion ways to do it
[22:55] Action: brg returned Tue Jun 22 22:44:30 2004 -- (hmm)
[22:55] <brg> hi what's up
[22:55] <sabre> read the last dozen lines
[22:55] <sabre> or so
[22:56] <sabre> maybe 2 or 3 dozen
[22:56] <brg> oh... bugmail?
[22:56] <sabre> da
[22:56] <DannyB> i hacked up bugzilla_email_append to be actually useful
[22:56] <DannyB> as opposed to a useless piece of crap
[22:57] <sabre> Do you know anything about the bugmail stuff in bugz brg?
[22:57] <brg> i haven't looked into it much, other than to implement the llvmbugs list
[22:57] <DannyB> what is the reply-to on llvmbugs?
[22:58] <DannyB> for gcc-bugs, we have the reply-to go to the comment appending script, and make sure people don't cc the list again
[22:58] <sabre> llvmbugs just gets mail when a bug is opened and resolved
[22:58] <DannyB> oh
[22:58] <sabre> But bugz sends out emails to people on the CC line for every change
[22:58] <sabre> (of course)
[22:58] <DannyB> what version of bugzilla are you guys using?
[22:59] <sabre> llvmbugs is designed for people who want to keep track of stuff bug not get overwhelmed
[22:59] <sabre> j/s
[22:59] <brg> 2.16.something
[22:59] <DannyB> ah
[22:59] <DannyB> the script might not work with 2.16.*
[22:59] <sabre> Here's the archives for llvmbugs: http://mail.cs.uiuc.edu/pipermail/llvmbugs/
[22:59] <DannyB> Well, without some changes
[22:59] <brg> someday we ought to upgrade to 2.17, but it's been a pretty low priority task
[22:59] <sabre> and bugz itself: http://llvm.cs.uiuc.edu/bugs/
[23:00] <DannyB> See, for example, rather than seeing
[23:00] <DannyB> bugzilla-daemon@cs.uiuc.edu bugzilla-daemon@cs.uiuc.edu
[23:00] <DannyB> "
[23:00] <DannyB> sabre@nondot.org changed:
[23:00] <DannyB> "
[23:00] <DannyB> you'll see "sabre at nondot dot org" bugzilla-daemon@cs.uiuc.edu
[23:00] <DannyB> in the from
[23:00] <sabre> that would be nice, but the report does say who it's from. It's annoying but works
[23:00] <DannyB> this was actually a rather simple change
[23:00] <sabre> I beleive it
[23:00] <sabre> it could be cool
[23:00] <sabre> because then the subject lines are more useful :slight_smile:
[23:00] <DannyB> well, whatevery you guys want
[23:01] <sabre> what do you think brg?
[23:01] <DannyB> i'm just offering the neurons i've used maintaining gcc bugzilla :slight_smile:
[23:01] <sabre> I think that setting the 'name' would be cool
[23:01] <sabre> This is pretty useless, for example: http://mail.cs.uiuc.edu/pipermail/llvmbugs/2004-June/thread.html
[23:01] <brg> i don't feel like i have the time to overhaul bugzilla at the moment
[23:02] <sabre> But just replying to mails would be the killer feature
[23:02] <sabre> Do you have some links to point me at dan?
[23:02] <sabre> links being files?
[23:02] <DannyB> in the gcc bugs mail, or in terms of source?
[23:02] <sabre> the source
[23:02] <DannyB> one sec
[23:03] <sabre> btw, target triples aren't super useful to us, because we always build cross compilers
[23:03] <DannyB> i figured as much :slight_smile:
[23:03] <sabre> a bug in the X86 target is just that
[23:03] <DannyB> it's also somewhat invasive anyway
[23:03] <sabre> you can hit it on sparcs
[23:04] <sabre> (not because sparcs use the X86 target, but because they CAN)
[23:04] Action: sabre shrugs
[23:04] <DannyB> this is our bugzilla_email_append
[23:04] <DannyB> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/wwwdocs/bugzilla/contrib/bugzilla_email_append.pl?rev=1.20&content-type=text/x-cvsweb-markup
[23:04] <DannyB> it requires
[23:04] <DannyB> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/wwwdocs/bugzilla/contrib/BugzillaEmail.pm?rev=1.7&content-type=text/x-cvsweb-markup
[23:04] <DannyB> that
[23:04] <DannyB> and that's it
[23:05] <sabre> did you completely rewrite this thing?
[23:05] <DannyB> I can't honestly remember anymore :slight_smile:
[23:05] <DannyB> I hate perl
[23:05] Action: sabre agrees vigorously
[23:06] <DannyB> me must go to bed
[23:06] <sabre> So I really don't know much about bugzilla.
[23:06] <sabre> What changes between versions? DB layout?
[23:06] <DannyB> 2.16->2.17 is a db layout change
[23:06] <sabre> ok, sounds good, we can chat about this tomorrow.
[23:06] <sabre> ok
[23:06] <DannyB> bugzilla is usually years between point releases unfortunately
[23:06] <sabre> Will you be around tomorrow afternoon sometime?
[23:06] <DannyB> yes
[23:07] <DannyB> i'll be around all day tomorrow
[23:07] <sabre> Ok, we should get _misha_ around
[23:07] <DannyB> hacking loop transforms
[23:07] <sabre> in on this
[23:07] <DannyB> okeydokey
[23:07] <sabre> cool, hopefully the LLVM ones :slight_smile:
[23:07] <sabre> sounds good, thanks for the ptrs
[23:07] <DannyB> Hand me classic distance and direction vectors, and I'll hand you a loop transformer :slight_smile:
[23:08] <sabre> Hrm, yeah well we don't have dep analysis yet.
[23:08] <sabre> It would be pretty easy to build it out of the SCEV + AA code
[23:08] <DannyB> right
[23:08] <sabre> If nothing else, we do have a robust AA infrastructure :slight_smile:
[23:08] <DannyB> which is why i'm working slow. I let sebastian implement the dependency analysis stuff in GCC
[23:08] <DannyB> :slight_smile:
[23:08] <sabre> heh
[23:08] <sabre> Which it seems like he has issues with
[23:09] <DannyB> The closest i like to get to dependence analysis is to touch the result
[23:09] <DannyB> s
[23:09] <sabre> as an outsider observation
[23:09] <DannyB> no, it works fine, actually
[23:09] <DannyB> we've just been removing the experimental scalar evolutions recently
[23:09] <sabre> k
[23:09] <brg> i'll see if i can figure out what it would take to upgrade to a recent bugzilla
[23:09] <DannyB> we'll add them back as we prove they are useful
[23:09] <sabre> I saw intervals just disappear
[23:09] <DannyB> brg: That isn't specifically necessary
[23:09] <DannyB> Do you guys have intervals?
[23:09] <sabre> no
[23:09] <DannyB> Right. :slight_smile:
[23:09] <sabre> I didn't think they would make much of a difference at all
[23:09] <DannyB> Right :slight_smile:
[23:10] <sabre> likewise with exp nodes
[23:10] <DannyB> Hence, why we are removing them for now
[23:10] <sabre> yah
[23:10] <DannyB> exponential will be removed as well, if it's not gone
[23:10] <sabre> I was much more interested in only implementing stuff that won't break programs :slight_smile:
[23:10] <DannyB> brg: I can make the script work with 2.16
[23:10] <sabre> Hence we're VERY conservative about integer wrap around and stuff
[23:10] <brg> er, ok
[23:11] <DannyB> brg: I'm pretty sure, anyway
[23:11] <DannyB> brg: I don't believe the longdesc format changed
[23:12] <sabre> Ok, well if you guys want to continue this tomorrow afternoon, we can drag misha in
[23:12] <DannyB> okey
[23:12] <sabre> Thanks Dan!
[23:13] <brg> i think i'll at least update to 2.16.5
[23:13] <sabre> brg: that would be cool
[23:15] <sabre> brg: did you just do something to bugzilla?
[23:15] <sabre> It seems like it just got unwedged or something
[23:15] <brg> yup, i upgraded it to 2.16.5, and fixed the sanity check error that i got
[23:15] <sabre> already??
[23:15] <brg> i think it let loose with a bunch of old mail
[23:15] <sabre> ya
[23:15] <brg> yeah it's pretty easy to do the minor upgrades
[23:16] <sabre> cool :slight_smile:
[23:16] <sabre> Thanks!

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:

Starting program:
/mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load
../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bc

Program received signal SIGSEGV, Segmentation fault.
0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
    at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
69 return isa_impl<To,FromTy>(Val);
(gdb) bt
#0 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
    at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
#1 0x083b69f7 in isa<llvm::Instruction> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80
#2 0x083b693f in isa<llvm::Instruction> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:90
#3 0x083b6673 in isa<llvm::Instruction> (Val=0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99
#4 0x083b6379 in isa<llvm::Instruction, const llvm::Value*>
(Val=@0xbf8000c0) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:114
#5 0x083b608f in llvm::CallInst::classof(llvm::Value const*) (V=0x894e850)
at /mounts/zion/disks/0/localhome/pmeredit/llvm/include/llvm/iOther.h:110
#6 0x08499213 in isa_impl<llvm::CallInst, llvm::Value> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:52
#7 0x08499157 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
    at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
#8 0x08498ea7 in isa<llvm::CallInst> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80
#9 0x08498b79 in isa<llvm::CallInst> (Val=0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99
#10 0x4001d1f6 in isa<llvm::CallInst> (Val=@0xbf800170) at
/localhome/pmeredit/llvm/include/Support/Casting.h:90
#11 0x4001cfb3 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Use const,
llvm::Value*>::doit(llvm::Use const&) (Val=@0xbf800200)
    at /localhome/pmeredit/llvm/include/Support/Casting.h:60
#12 0x4001ca1c in isa<llvm::CallInst> (Val=@0xbf800200) at
/localhome/pmeredit/llvm/include/Support/Casting.h:80
#13 0x4001c1ca in isa<llvm::CallInst, llvm::Use> (Val=@0xbf800200) at
/localhome/pmeredit/llvm/include/Support/Casting.h:114
#14 0x4001baaa in dyn_cast<llvm::CallInst, llvm::Use> (Val={Val = 0x894e850,
U = 0x8917e48, Prev = 0x895a240, Next = 0x894e880})
    at /localhome/pmeredit/llvm/include/Support/Casting.h:223
#15 0x4001af72 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8917e48) at MetaSplit.cpp:79
#16 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x895ff40) at MetaSplit.cpp:88
#17 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#18 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#19 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#20 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#21 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#22 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#23 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#24 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#25 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#26 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#27 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#28 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#29 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88

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:

Starting program:
/mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load
../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bc

This is a crash in your pass. Try running:

opt -mem2reg test3.s.bc -o tmp.bc
opt -load ... -metasplit tmp.bc -o out.bc

I suspect that it will still crash in only your pass (aka, the bug is
yours :slight_smile:

Regardless I recommend trying out bugpoint for something like this. Try
running:

bugpoint -load ... -mem2reg -metasplit test3.s.bc

and it will probably tell you what I just did, and give you a better
testcase. :slight_smile:

-Chris

Program received signal SIGSEGV, Segmentation fault.
0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
    at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
69 return isa_impl<To,FromTy>(Val);
(gdb) bt
#0 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
    at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
#1 0x083b69f7 in isa<llvm::Instruction> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80
#2 0x083b693f in isa<llvm::Instruction> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:90
#3 0x083b6673 in isa<llvm::Instruction> (Val=0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99
#4 0x083b6379 in isa<llvm::Instruction, const llvm::Value*>
(Val=@0xbf8000c0) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:114
#5 0x083b608f in llvm::CallInst::classof(llvm::Value const*) (V=0x894e850)
at /mounts/zion/disks/0/localhome/pmeredit/llvm/include/llvm/iOther.h:110
#6 0x08499213 in isa_impl<llvm::CallInst, llvm::Value> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:52
#7 0x08499157 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Value const,
llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
    at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69
#8 0x08498ea7 in isa<llvm::CallInst> (Val=@0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80
#9 0x08498b79 in isa<llvm::CallInst> (Val=0x894e850) at
/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99
#10 0x4001d1f6 in isa<llvm::CallInst> (Val=@0xbf800170) at
/localhome/pmeredit/llvm/include/Support/Casting.h:90
#11 0x4001cfb3 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Use const,
llvm::Value*>::doit(llvm::Use const&) (Val=@0xbf800200)
    at /localhome/pmeredit/llvm/include/Support/Casting.h:60
#12 0x4001ca1c in isa<llvm::CallInst> (Val=@0xbf800200) at
/localhome/pmeredit/llvm/include/Support/Casting.h:80
#13 0x4001c1ca in isa<llvm::CallInst, llvm::Use> (Val=@0xbf800200) at
/localhome/pmeredit/llvm/include/Support/Casting.h:114
#14 0x4001baaa in dyn_cast<llvm::CallInst, llvm::Use> (Val={Val = 0x894e850,
U = 0x8917e48, Prev = 0x895a240, Next = 0x894e880})
    at /localhome/pmeredit/llvm/include/Support/Casting.h:223
#15 0x4001af72 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8917e48) at MetaSplit.cpp:79
#16 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x895ff40) at MetaSplit.cpp:88
#17 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#18 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#19 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#20 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#21 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#22 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#23 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#24 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#25 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#26 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#27 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88
#28 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x89609a8) at MetaSplit.cpp:88
#29 0x4001b049 in (anonymous
namespace)::MetaSplit::handleProgramUses(llvm::Value*) (this=0x893e998,
V=0x8930610) at MetaSplit.cpp:88

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

-Chris

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

> 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:
>
> Starting program:
> /mounts/zion/disks/0/localhome/pmeredit/llvm/tools/Debug/opt -load
> ../Debug/libmetasplit.so -mem2reg -metasplit < test3.s.bc > out.bc

This is a crash in your pass. Try running:

opt -mem2reg test3.s.bc -o tmp.bc
opt -load ... -metasplit tmp.bc -o out.bc

I've already tried that and yes it crashes :wink:

I suspect that it will still crash in only your pass (aka, the bug is
yours :slight_smile:

Regardless I recommend trying out bugpoint for something like this. Try
running:

bugpoint -load ... -mem2reg -metasplit test3.s.bc

and it will probably tell you what I just did, and give you a better
testcase. :slight_smile:

-Chris

> Program received signal SIGSEGV, Segmentation fault.
> 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value const,
> llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
> at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69

> 69 return isa_impl<To,FromTy>(Val);
> (gdb) bt
> #0 0x083b6a22 in llvm::isa_impl_wrap<llvm::Instruction, llvm::Value

const,

> llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
> at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69

> #1 0x083b69f7 in isa<llvm::Instruction> (Val=@0x894e850) at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80

> #2 0x083b693f in isa<llvm::Instruction> (Val=@0x894e850) at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:90

> #3 0x083b6673 in isa<llvm::Instruction> (Val=0x894e850) at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99

> #4 0x083b6379 in isa<llvm::Instruction, const llvm::Value*>
> (Val=@0xbf8000c0) at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:114

> #5 0x083b608f in llvm::CallInst::classof(llvm::Value const*)

(V=0x894e850)

> at

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/llvm/iOther.h:110

> #6 0x08499213 in isa_impl<llvm::CallInst, llvm::Value> (Val=@0x894e850)

at

>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:52

> #7 0x08499157 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Value const,
> llvm::Value const>::doit(llvm::Value const&) (Val=@0x894e850)
> at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:69

> #8 0x08498ea7 in isa<llvm::CallInst> (Val=@0x894e850) at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:80

> #9 0x08498b79 in isa<llvm::CallInst> (Val=0x894e850) at
>

/mounts/zion/disks/0/localhome/pmeredit/llvm/include/Support/Casting.h:99

> #10 0x4001d1f6 in isa<llvm::CallInst> (Val=@0xbf800170) at
> /localhome/pmeredit/llvm/include/Support/Casting.h:90
> #11 0x4001cfb3 in llvm::isa_impl_wrap<llvm::CallInst, llvm::Use const,
> llvm::Value*>::doit(llvm::Use const&) (Val=@0xbf800200)
> at /localhome/pmeredit/llvm/include/Support/Casting.h:60
> #12 0x4001ca1c in isa<llvm::CallInst> (Val=@0xbf800200) at
> /localhome/pmeredit/llvm/include/Support/Casting.h:80
> #13 0x4001c1ca in isa<llvm::CallInst, llvm::Use> (Val=@0xbf800200) at
> /localhome/pmeredit/llvm/include/Support/Casting.h:114
> #14 0x4001baaa in dyn_cast<llvm::CallInst, llvm::Use> (Val={Val =

0x894e850,

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! 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).
Let me check bugpoint.

Okay, well then just use:

bugpoint -load ... -metasplit tmp.bc

It will give you a nice small testcase that illustrates a case that you
pass crashes on. Seriously: give bugpoint a try. It will probably give
you a 5-10 line testcase.

-Chris

Yes, it's actually an operand out of range. I'm still pointing a finger at
PHInodes though. Thanks for the help :slight_smile:

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. :slight_smile:

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. :slight_smile: 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 :slight_smile:

Let me check bugpoint.

Cool, post the testcase it produces. Hopefully it will be small :slight_smile:

-Chris

> 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. :slight_smile:

> 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. :slight_smile: 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 :slight_smile:

I am handling null, I'm using the if( something* s =
dyn_cast<something>(something_else){ } construct. It's the fact that I was
using getOperand(1) on a call instruction that should always have an
operand.... (the 0th operand is the function, the 1st should be the
paramter). For some reason this error only pops up after mem2reg. But I
need to change this so that I am not adding whole basic blocks to my program
value set anyway.

> Let me check bugpoint.

Cool, post the testcase it produces. Hopefully it will be small :slight_smile:

-Chris

> From: "Misha Brukman" <brukman@uiuc.edu>
> To: <llvmdev@cs.uiuc.edu>
> Sent: Wednesday, June 23, 2004 3:56 PM
> Subject: Re: [LLVMdev] weird issue with mem2reg
>
>
> > > 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

Second meaning operand 1.

Somehow it fails with operand out of bounds when the number of operands is 2
and I am asking for the second operand.

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

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.

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