[llvm-commits] [llvm] r77397 - in /llvm/trunk: include/llvm/Support/FormattedStream.h lib/Support/FormattedStream.cpp

[Evan Cheng]

Dave, I am pretty sure you are experienced enough to know that a patch  
has the potential to disrupt.

That said. We all make mistakes. But when it's pointed out, we all do  
our best to recover from that mistake. When it's not obvious, or when  
we don't have the time to deal with it. We back out the change.

In this case, it has been pointed out to you repeatedly your changes  
caused 30% compile time regression on Mac and Linux 64. We have waited  
quite a long time before reverting the change. Please do what you can  
to ensure your subsequent changes do not re-introduce the problem.  
Saying that you can't test it doesn't make it ok. Playing trial and  
error on TOT is not acceptable.

Evan

On Jul 29, 2009, at 1:11 PM, David Greene wrote:

> On Wednesday 29 July 2009 15:02, Evan Cheng wrote:
>
>>> I have no problem with this in principle, but running test-suite
>>> before
>>> every commit is not practical.  What we need is something in the  
>>> LLVM
>>> tests that handles compile-time and performance regression.
>>
>> Why not? If the change has a potential to cause noticeable changes to
>> performance / compile time / code size. Then running the test suite  
>> is
>> a requirement.
>
> How is one supposed to know _a_priori_?
>
>                               -Dave
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits