+  for (unsigned i = 0, e = FunctionsBeingTested.size(); i !=e; ++i) {<div><br></div><div>Space after '!=' and before 'e' please.</div><div><br></div><div>+  for (unsigned i = 0, e = BBs.size(); i !=e; ++i) {</div>

<div><br></div><div>Here too!</div><div><br></div><div>Looks good!</div><div><br><div class="gmail_quote">On 25 July 2010 17:21, Rafael Espindola <span dir="ltr"><<a href="mailto:espindola@google.com">espindola@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Do you want to use a SmallVector here?<br>
<br>
</div>It is passed to a function and I wanted to avoid changing the<br>
interface. I implemented the other suggestions.<br>
<br>
The attached patch does a similar thing to the block reduction logic.<br>
With it bugpoint can run without crashing on the testcase I am trying<br>
to reduce.<br>
<br>
I did noticed another less serious problem with bugpoint that I might<br>
try to fix in another patch: When splitting the module into two parts,<br>
it will copy the functions it wants to optimize. When doing that it<br>
changes internal functions into regular ones and this sometimes masks<br>
the bug.<br>
<br>
For example, say a module has f1, f2 and f3. f2 is internal and the<br>
bug can be reproduced with only f1 and f2 but is masked if f2 is not<br>
internal. Bugpoint will fail to remove f3.<br></blockquote><div><br></div><div>Generating testcases that are too large isn't my big worry with bugpoint. I'm much more concerned about things like marking (or not marking) a function fastcc as a result of it being inline.</div>

<div><br></div><div>Nick</div></div></div>