When bugpoint runs something (gcc, or a probably-broken bit of code), it should have some limits on disk and memory usage set, to add a bit of determinism and be more polite. I just went through a bugpoint run where the code in question was failing by exhausting swap - worked fine, just took 20x longer than it should have. This issue will probably become more serious if and when bugpoint gets multithreaded.
I would argue that such things are outside the scope of LLVM. If you want to limit bugpoint's cpu/memory/disk, you should be able to do that prior to invoking bugpoint from the environment of the operating system. I don't think we should implement this unless there is a strong counter-argument.
I don't really agree. Bugpoint can run for a long time and potentially consume a lot of time and memory. The executed programs, however, should have well known time/space requirements that we want to contain should they spin out of control. -Chris
okay, care to define those limits? isn't the limit somewhat dependent on the input? and, what about gccld, llvm-ld, or other programs which might execute for a whlie? if we have to support this feature, then we have to do it on all platforms .. is it worth the effort?
I think that having bugpoint default to large but reasonable limits (e.g. 100M of memory and 1 minute of run time), but allowing command line options to change the default is best. Hosts that don't support the "setlimit" family of functions can just ignore the request. -Chris
Seems to be easy to add. Are there "setrlimit" call on Darwin?
Yep, darwin has setrlimit, -Chris
One thing that I recently noticed is that the --timeout=N value only applies to the program when it is being run. It does not apply to tool executions like llc or bugpoint when it forks itself to run optimizations. -Chris
memory limit introduced in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044634.html ... http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070212/044643.html Something more to add?
Very nice! Can you also investigate making sub-invocations of llc respect -timeout? If llc goes into an infinite loop, bugpoint can't help. An easy way to test this is to add "while (1);" to llc's main, then do bugpoint-llc on something. bugpoint should reduce it down to a single empty function. -Chris
anton implemented this.