Re: gcc 3.4 mainline performance regression

2007-01-05 Thread Ian Lance Taylor
Andrew Haley [EMAIL PROTECTED] writes: It appears that memory references to arrays aren't being hoisted out of loops: in this test case, gcc 3.4 doesn't touch memory at all in the loop, but 4.3pre (and 4.2, etc) does. Here's the test case: void foo(int *a) { int i; for (i

Re: gcc 3.4 mainline performance regression

2007-01-05 Thread Steven Bosscher
On 05 Jan 2007 07:18:47 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote: At the tree level, the problem is that the assignment to a[0] is seen as aliasing a[1]. This causes the use of a[1] to look like a USE of an SMT, and the assignment to a[0] to look like a DEF of the same SMT. So in

Re: gcc 3.4 mainline performance regression

2007-01-05 Thread Steven Bosscher
On 1/5/07, Andrew Haley [EMAIL PROTECTED] wrote: This is from the gcc-help mailing list. It's mentioned there for ARM, but it's just as bad for x86-64. It appears that memory references to arrays aren't being hoisted out of loops: in this test case, gcc 3.4 doesn't touch memory at all in the

Re: gcc 3.4 mainline performance regression

2007-01-05 Thread David Edelsohn
Steven Bosscher writes: Steven What does the code look like if you compile with -O2 -fgcse-sm? Yep. Mark and I recently discussed whether gcse-sm should be enabled by default at some optimization level. We're hiding performance from GCC users. David

Re: gcc 3.4 mainline performance regression

2007-01-05 Thread Andrew Haley
Steven Bosscher writes: On 1/5/07, Andrew Haley [EMAIL PROTECTED] wrote: This is from the gcc-help mailing list. It's mentioned there for ARM, but it's just as bad for x86-64. It appears that memory references to arrays aren't being hoisted out of loops: in this test case, gcc

Re: gcc 3.4 mainline performance regression

2007-01-05 Thread Steven Bosscher
On 1/5/07, David Edelsohn [EMAIL PROTECTED] wrote: Steven Bosscher writes: Steven What does the code look like if you compile with -O2 -fgcse-sm? Yep. Mark and I recently discussed whether gcse-sm should be enabled by default at some optimization level. We're hiding performance

Re : gcc 3.4 mainline performance regression

2007-01-05 Thread Mick CORNUT
- Message d'origine De : Steven Bosscher [EMAIL PROTECTED] À : David Edelsohn [EMAIL PROTECTED] Cc : Andrew Haley [EMAIL PROTECTED]; gcc@gcc.gnu.org Envoyé le : Vendredi, 5 Janvier 2007, 17h55mn 47s Objet : Re: gcc 3.4 mainline performance regression On 1/5/07, David Edelsohn [EMAIL PROTECTED

Re: Re : gcc 3.4 mainline performance regression

2007-01-05 Thread Andrew Haley
Please don't top-post. It's very confusing. Mick CORNUT writes: I don't know exactly if I've understood all your previous explanation (excepted the load store motion part), but we pointed out 2 different problems: Pb n°1: depending on the optimization level -03, a[0] and a[1] are

Re: gcc 3.4 mainline performance regression

2007-01-05 Thread Daniel Berlin
On 05 Jan 2007 07:18:47 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote: Andrew Haley [EMAIL PROTECTED] writes: It appears that memory references to arrays aren't being hoisted out of loops: in this test case, gcc 3.4 doesn't touch memory at all in the loop, but 4.3pre (and 4.2, etc) does.