https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-* i?86-*-*
--- Comment #21 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
--- Comment #20 from Richard Biener ---
(In reply to Andrew Pinski from comment #19)
> (In reply to Andrew Pinski from comment #18)
> > This is what is produced (at least for 7.3.0):
> Which has been produced since GCC 6.
> that is due to ifcvt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
--- Comment #19 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #18)
> This is what is produced (at least for 7.3.0):
Which has been produced since GCC 6.
that is due to ifcvt.c changes.
On the trunk we can produce on the gimple no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
--- Comment #18 from Andrew Pinski ---
This is what is produced (at least for 7.3.0):
movla(%rip), %edx
movl$0, %eax
leal2(%rdx), %ecx
cmpl$-1, %edx
cmovne %ecx, %eax
movl%eax,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
--- Comment #17 from Richard Guenther 2011-03-15
11:24:13 UTC ---
(In reply to comment #16)
> To optimize
>
> void foo() {
> extern int a;
> if(++a) ++a;
> }
>
> we need to have partial dead store elimination, basically sink the
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-02-13 10:23
---
To optimize
void foo() {
extern int a;
if(++a) ++a;
}
we need to have partial dead store elimination, basically sink the store
to after the condition:
void bar() {
extern int a;
int tmp =
--- Comment #15 from steven at gcc dot gnu dot org 2010-02-12 21:58 ---
GCC still doesn't get it right for this PR. The .139t.optimized dump for trunk
r156706:
;; Function foo (foo)
foo ()
{
int a.1;
int a.0;
:
a.0_1 = a;
a.1_2 = a.0_1 + 1;
a = a.1_2;
if (a.1_2 != 0)
g
--- Comment #14 from steven at gcc dot gnu dot org 2008-09-21 13:52 ---
Here is the .final_cleanup dump, fwiw:
;; Function foo (foo)
foo ()
{
int a.1;
:
a.1 = a + 1;
a = a.1;
if (a.1 != 0)
goto ;
else
goto ;
:
a = [plus_expr] a.1 + 1;
:
return;
}
which trans
--- Comment #13 from steven at gcc dot gnu dot org 2008-09-21 13:49 ---
Re. comment #12
I don't see how PRE for globals would make a difference here. In any case,
AFAIU tree PRE for globals should now work, and we still don't produce any
better code. The output of today (4.4.0 20080921)
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-03-20 09:28
---
This bug is just a dup of the tree-PRE doesn't work for globals bug (if we have
one for that).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
--- Comment #11 from michaelni at gmx dot at 2006-02-11 13:54 ---
(In reply to comment #9)
> Re. comment #8:
> "exponential decaying performance which it has so accurately followed since
> 2.95"
>
> Can you back this up with numbers, or are you just trolling? If the latter,
> please do
--- Comment #10 from steven at gcc dot gnu dot org 2006-02-11 13:14 ---
This is, in fact, a rare case where RTL store motion does something useful.
With "-O2 -fomit-frame-pointer -march=pentium4" we produce:
movla, %eax
addl$1, %eax
movl%eax, a
--- Comment #9 from steven at gcc dot gnu dot org 2006-02-11 13:02 ---
Re. comment #8:
"exponential decaying performance which it has so accurately followed since
2.95"
Can you back this up with numbers, or are you just trolling? If the latter,
please don't do that, you are insulting t
--- Comment #8 from michaelni at gmx dot at 2006-02-11 11:40 ---
I really think this should be fixed, otherwise gcc wont be able to follow its
exponential decaying performance which it has so accurately followed since 2.95
at least, to show clearer how much speed we could loose by fixing
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-11 00:52 ---
"GCC: (GNU) 4.2.0 20060210 (experimental)" produces this
(at "-O2 -march=pentium4"):
foo:
movla, %eax
addl$1, %eax
movl%eax, a
testl %eax, %eax
je .L4
15 matches
Mail list logo
