From 90f86a79c4cb0493beeaf0ffb8a1fddc380c5fb2 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Sun, 19 Oct 2003 17:27:12 +0000 Subject: [PATCH] Two minor fixes llvm-svn: 9256 --- llvm/docs/CommandGuide/bugpoint.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/llvm/docs/CommandGuide/bugpoint.html b/llvm/docs/CommandGuide/bugpoint.html index e9d0b58..5593e57 100644 --- a/llvm/docs/CommandGuide/bugpoint.html +++ b/llvm/docs/CommandGuide/bugpoint.html @@ -27,7 +27,7 @@ crash, and reduce the file down to a small example which triggers the crash.

Design Philosophy

-bugpoint has been designed to be a useful tool without requiring any +bugpoint is designed to be a useful tool without requiring any hooks into the LLVM infrastructure at all. It works with any and all LLVM passes and code generators, and does not need to "know" how they work. Because of this, it may appear to do a lot of stupid things or miss obvious @@ -70,7 +70,7 @@ If an optimizer crashes, bugpoint will try as hard as it can to reduce the list of passes and the size of the test program. First, bugpoint figures out which combination of passes triggers the bug. This is useful when debugging a problem exposed by gccas, for example, -because it runs over 30 optimizations.

+because it runs over 25 optimizations.

Next, bugpoint tries removing functions from the module, to reduce the size of the test program. Usually it is able to reduce a test program -- 2.7.4