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) d
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] a
ick 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]> 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 performa
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
> 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
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
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 tree-
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;
>
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 loop, but 4.3pre (and 4.2, etc) does.
Here's the t
10 matches
Mail list logo
