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

[Richard Smith]

On Fri, Jun 21, 2013 at 11:18 AM, John McCall <rjmccall at apple.com> wrote:
> 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.

Yes, I agree. I'd even be happy to drop the test case entirely, if
no-one objects; it was only ever indirectly testing the fix.