assigned to @asl

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.