--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10
09:08 ---
The slowdown is probably some unfortunate icache effect - ccould be anything
from alignment, the slightly larger instructions due to using r8 instead of
rcx. I guess we should not care too much about such
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10
10:06 ---
'size' for susan_edged_mod_1 .o files
33 = pre 3.3.3-suse (hammer branch
40 = CVS head 20050209
patched = CVS head 20050209 with the 'TER hack' patch applied.
i686:
textdata bss dec
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-10
21:11 ---
(In reply to comment #37)
So for ppc this bug is still not fixed even with my patch. Interesting data
point is the ppc32 size with -Os -fno-ivopts:
2820 0 02820 b04 no-ivopts.o
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-10
22:57 ---
Subject: Bug 17549
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-10 22:57:31
Modified files:
gcc: ChangeLog tree-outof-ssa.c
Log
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-10
22:59 ---
.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-09
22:00 ---
My TER hack does fix most of the problems, but it also causes a significant
regression in the SPEC twolf benchmark. All other benchmarks are roughly the
same. I'll try to figure out what is causing the
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-09
23:35 ---
The entire diff of .optimized dumps and .s output for twolf on AMD64 is really
small, in fact the asm output is different for only one file:
config1.c.t65.optimized | 120
--- Additional Comments From amacleod at redhat dot com 2005-02-08 14:02
---
(In reply to comment #30)
Subject: Re: [4.0 Regression] 10% increase in codesize with C code compared
to GCC 3.3
On Mon, Feb 07, 2005 at 11:13:27PM -, steven at gcc dot gnu dot org wrote:
x = a +
--- Additional Comments From amacleod at redhat dot com 2005-02-08 14:26
---
(In reply to comment #28)
Using var_to_partition does not help. The reason is that the SSA names with
the same root var are not in the same partition, e.g.
retval_7 -- retval
x_3 -- x
x_4 not
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-07
23:13 ---
Using var_to_partition does not help. The reason is that the SSA names with
the same root var are not in the same partition, e.g.
int
foo (int x, int a, int b)
{
x = a + b;
x = x * a;
x = x *
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-07
23:16 ---
Note the following:
x_4 not coalesced with x -- New temp: 'x.0'
x_5 not coalesced with x.0 -- New temp: 'x.1'
Not very useful, because x_4 and x_5 have no uses left. So you start with
this:
foo
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-07 23:36
---
Subject: Re: [4.0 Regression] 10% increase in codesize with C code compared to
GCC 3.3
On Mon, Feb 07, 2005 at 11:13:27PM -, steven at gcc dot gnu dot org wrote:
x = a + b;
x = x * a;
x = x *
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
00:15 ---
Might as well make it mine while I'm looking at it.
--
What|Removed |Added
--- Additional Comments From amacleod at redhat dot com 2005-02-03 14:37
---
(In reply to comment #23)
We have incomming into out-of-ssa,
x.1 = exp1
x.2 = x.1 + exp2
x.3 = x.2 + exp3
We're currently allowing TER to produce
x.3 = exp1 + exp2 + exp3
What if we
--- Additional Comments From giovannibajo at libero dot it 2005-02-03
15:15 ---
Are we looking to do this at -O2 as well? I guess thats a key question.
at just -Os, it might very well be sufficient.
As stevenb noted today in IRC, the code reduction substantially comes from less
--- Additional Comments From amacleod at redhat dot com 2005-02-03 16:05
---
(In reply to comment #26)
Are we looking to do this at -O2 as well? I guess thats a key question.
at just -Os, it might very well be sufficient.
As stevenb noted today in IRC, the code reduction
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-03 02:23
---
The balance of the problem appears to come from TER. We're building very large
constructs, such as
[z.c : 76] x.182 = -temp.218 + temp.220 - temp.688 - temp.222 + temp.224 +
temp.692 - temp.226 * 3 -
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-03
02:38 ---
(In reply to comment #19)
The balance of the problem appears to come from TER. We're building very
large
constructs, such as
Hmm, shouldn't the register allocator fix this anyways (yes I know we have
--- Additional Comments From amacleod at redhat dot com 2005-02-03 03:23
---
(In reply to comment #19)
The balance of the problem appears to come from TER. We're building very
large
constructs, such as
...
I'm not sure how best to attack this, Andrew. I think it's clear that
--- Additional Comments From amacleod at redhat dot com 2005-02-03 03:27
---
(In reply to comment #20)
(In reply to comment #19)
The balance of the problem appears to come from TER. We're building very
large
constructs, such as
Hmm, shouldn't the register allocator fix this
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-03 06:37
---
We have incomming into out-of-ssa,
x.1 = exp1
x.2 = x.1 + exp2
x.3 = x.2 + exp3
We're currently allowing TER to produce
x.3 = exp1 + exp2 + exp3
What if we were to disable TER substitution when
21 matches
Mail list logo
