r174685 - Fix stack overflow and improve performance when a module contains many

John McCall rjmccall at apple.com
Fri Jun 21 11:18:46 PDT 2013


On Jun 21, 2013, at 1:30 AM, Chandler Carruth <chandlerc at google.com> wrote:
> On Thu, Jun 20, 2013 at 6:15 PM, John McCall <rjmccall at apple.com> wrote:
> On Jun 20, 2013, at 12:37 AM, Chandler Carruth <chandlerc at google.com> wrote:
>> On Thu, Feb 7, 2013 at 4:37 PM, Richard Smith <richard-llvm at metafoo.co.uk> wrote:
>> cfe/trunk/test/Modules/cxx-many-overloads.cpp
>> 
>> Hate to dig up this test, but I wanted to mention that this is the single slowest test in the regression test suite for me at 28.84s... Wondered if you had any ideas about making it cheaper.
> 
> Maybe it would just more appropriate in a different test suite?  I believe there are a number of bots that run clang-tests, and getting 100% platform coverage doesn't seem completely imperative here.
> 
> My suspicion (which is nothing more as I've not investigated) is that this is testable with a reasonable cheap test, and having in the basic 'make check' pattern seems worthwhile on the whole. But certainly if the first proves to not be the case, we shouldn't keep it here just for the second... 

If it can be made efficient, then absolutely it can and should stay.  But 'make check' is never going to be an exhaustive test suite, and tying up a core for a long time (even on your presumably quite beefy machine) in a deliberate stress test feels like something that really belongs in a secondary test suite like clang-tests, especially to test a fix that honestly does not seem particularly fragile.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130621/f774c9df/attachment.html>


More information about the cfe-commits mailing list