From 129e7a88b01e521a0fa20ec233eb0d1dbd389dae Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Sun, 19 Oct 2003 17:27:12 +0000 Subject: [PATCH] Two minor fixes git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9256 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CommandGuide/bugpoint.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/CommandGuide/bugpoint.html b/docs/CommandGuide/bugpoint.html index e9d0b587c9a..5593e57c5da 100644 --- a/docs/CommandGuide/bugpoint.html +++ b/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