On Tue, Oct 11, 2011 at 8:54 PM, Richard Sandiford richard.sandiford@linaro.org wrote:

Michael Hope michael.hope@linaro.org writes:

...

limits-fndefn.c takes an impressively long time to run.   On an idle machine, -O3 -g -c takes 17:31 and -O2 -g -c takes   The test already has a dg-timeout-factor of 4 giving a total timeout of 20 minutes.

Removing the -g brings this down to 30 s.  Keeping the -g and adding -fno-var-tracking brings this down to 45 s.

We could bump the multiplier up to 8 but it's getting a bit ridiculous.

I agree.

...

Any thoughts?

I remember Mark made a convincing case that these sorts of test don't belong in the main testsuite.  They add to people's testing time but (a) don't represent real testcases and (b) aren't going to be affected by the vast majority of patches.  And whether they pass or not depends as much on how much virtual memory is available as much as anything else.

I think the idea was that they would be moved to a different testsuite that is only run on demand.  Then (hopefully) regular automatic testers like H.J.'s would run this extra testsuite too.  But I don't think a consensus was ever reached...

OK. We'll check but generally accept any changes in limit test results.

Separately, does this show a performance problem with var tracking? Turning on var tracking leads to a 20 x slow down in this particular case.

-- Michael

On Thu, Oct 13, 2011 at 1:03 AM, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:

Michael Hope michael.hope@linaro.org wrote:

...

Separately, does this show a performance problem with var tracking? Turning on var tracking leads to a 20 x slow down in this particular case.

I'd agree that is a performance problem; probably some nonlinear behaviour in the var tracking algorithms.  B.t.w. I'd say that catching such issues is one of the reasons to have those extreme limits tests in the first place ...

There's no real change with current trunk. I've logged PR50770 so that others know about it.

-- Michael