Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-25 Thread Richard Guenther
On Wed, Jul 25, 2012 at 1:59 PM, Steven Bosscher wrote: > On Wed, Jul 25, 2012 at 1:49 PM, Richard Guenther > wrote: >> Oh, bigger bitmap_head? That's bad ... :/ So much for '#ifdefs are bad' :/ > > Bigger bitmap_head isn't a problem. A bigger bitmap_element would be bad. > > For GGC allocated

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-25 Thread Steven Bosscher
On Wed, Jul 25, 2012 at 1:49 PM, Richard Guenther wrote: > Oh, bigger bitmap_head? That's bad ... :/ So much for '#ifdefs are bad' :/ Bigger bitmap_head isn't a problem. A bigger bitmap_element would be bad. For GGC allocated bitmaps, nothing changed (rounding, etc.). If you think it's a prob

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-25 Thread Richard Guenther
On Tue, Jul 24, 2012 at 7:13 PM, Steven Bosscher wrote: >> AFAIR the qsort is just for getting a stable ordering over two pools to find >> the leaked regsets afterwards, the type of ordering doesn't matter. > > What matters is that the compare function gives a reliable result. You > can't subtract

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Andrey Belevantsev
On 24.07.2012 21:13, Steven Bosscher wrote: AFAIR the qsort is just for getting a stable ordering over two pools to find the leaked regsets afterwards, the type of ordering doesn't matter. What matters is that the compare function gives a reliable result. You can't subtract pointers like that f

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Steven Bosscher
On Tue, Jul 24, 2012 at 7:53 PM, Jason Merrill wrote: > On 07/23/2012 01:01 PM, Steven Bosscher wrote: >> >> This large patch makes GATHER_STATISTICS always take a value, 0 >> (disabled) or 1 (enabled), and turns all related #ifdef code into >> conditional branches. > > > Did you test this with --

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Jason Merrill
On 07/23/2012 01:01 PM, Steven Bosscher wrote: This large patch makes GATHER_STATISTICS always take a value, 0 (disabled) or 1 (enabled), and turns all related #ifdef code into conditional branches. Did you test this with --enable-gather-detailed-mem-stats? It didn't build for me, so I fixed

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Steven Bosscher
> AFAIR the qsort is just for getting a stable ordering over two pools to find > the leaked regsets afterwards, the type of ordering doesn't matter. What matters is that the compare function gives a reliable result. You can't subtract pointers like that for qsort. After consulting the experts on

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Andrey Belevantsev
Hello, On 24.07.2012 18:56, Steven Bosscher wrote: On Tue, Jul 24, 2012 at 4:37 PM, Steven Bosscher wrote: On Tue, Jul 24, 2012 at 3:08 PM, Uros Bizjak wrote: This patch (r189803) regressed a bunch of tests on x86_64 [1], [2]. [1] http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02066.html

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Steven Bosscher
On Tue, Jul 24, 2012 at 6:21 PM, Markus Trippelsdorf wrote: > On 2012.07.23 at 19:01 +0200, Steven Bosscher wrote: >> Hello, >> >> This large patch makes GATHER_STATISTICS always take a value, 0 >> (disabled) or 1 (enabled), and turns all related #ifdef code into >> conditional branches. >> >> Thi

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Markus Trippelsdorf
On 2012.07.23 at 19:01 +0200, Steven Bosscher wrote: > Hello, > > This large patch makes GATHER_STATISTICS always take a value, 0 > (disabled) or 1 (enabled), and turns all related #ifdef code into > conditional branches. > > This slightly increases the data section of cc1, but only marginally. >

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Steven Bosscher
On Tue, Jul 24, 2012 at 4:37 PM, Steven Bosscher wrote: > On Tue, Jul 24, 2012 at 3:08 PM, Uros Bizjak wrote: >> This patch (r189803) regressed a bunch of tests on x86_64 [1], [2]. >> >> [1] http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02066.html >> [2] http://gcc.gnu.org/ml/gcc-regression/20

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Steven Bosscher
On Tue, Jul 24, 2012 at 3:08 PM, Uros Bizjak wrote: > This patch (r189803) regressed a bunch of tests on x86_64 [1], [2]. > > [1] http://gcc.gnu.org/ml/gcc-testresults/2012-07/msg02066.html > [2] http://gcc.gnu.org/ml/gcc-regression/2012-07/msg00177.html These are all selective-scheduler test cas

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Uros Bizjak
Hello! > This large patch makes GATHER_STATISTICS always take a value, 0 > (disabled) or 1 (enabled), and turns all related #ifdef code into > conditional branches. > This slightly increases the data section of cc1, but only marginally. > There is no impact on compile time, because all tests are

Re: [patch] un-#ifdef GATHER_STATISTICS

2012-07-24 Thread Richard Guenther
On Mon, Jul 23, 2012 at 7:01 PM, Steven Bosscher wrote: > Hello, > > This large patch makes GATHER_STATISTICS always take a value, 0 > (disabled) or 1 (enabled), and turns all related #ifdef code into > conditional branches. > > This slightly increases the data section of cc1, but only marginally.