--- Comment #11 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-07-12 23:39 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> I-cache.
this only matters if this increase in code size will make the code go
out of i
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-07-13 01:11
---
Fixed on the mainline at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-07-13 01:11
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
Compile the following code with -maltivec -O2 -mabi=altivec -m64:
#define vector __attribute__((vector_size(16)))
vector float f(vector float t, vector float t1)
{
return t / t1;
}
We currently get:
addi 9,1,-36
stvewx 2,0,9
addi 9,1,-20
stvewx 3,0,9
addi 9
Take the following code and compile with -O2 -m64 -maltivec -mabi=altivec:
#define vector __attribute__((vector_size(16)))
float f(vector float t)
{
union {
vector float t1;
float t2[4];
}t5;
t5.t1 = t;
return t5.t2[0];
}
Currently we get:
addi 12,1,-32
stvx 2,0,12
--- Comment #12 from zackw at panix dot com 2006-07-13 03:09 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> > I-cache.
> this only matters if this increase in code size will make the code go
> out of instruction cache.
The re
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-13 03:37
---
Hmm, for some reason I don't like the idea of using std::string in the inner
loop :). Even the C testcase does not seem like a good inner loop in general
anyways as there is no caculation going on here. To me the
--- Comment #14 from zackw at panix dot com 2006-07-13 03:40 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
It's a validation routine, yes, which is run over every pathname the
program is working on, and there can be hundreds or
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-07-13 03:45
---
One more comment, a loop with an early exit is whole issue and that is the
reason why all of the code in the loop is considered the header. There are a
couple of loop headers in this case, one for each exit which m
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-07-13 04:01
---
If this is really a program's inner most loop, then the program is messed up as
there is no caculation going on here at all.
What type of program is this? Do you cache the result of this function? Maybe
chaching
--- Comment #17 from zackw at panix dot com 2006-07-13 04:23 ---
Subject: Re: poor optimization choices when iterating over a std::string
(probably not c++-specific)
> One more comment, a loop with an early exit is whole issue and that is the
> reason why all of the code in the loop is
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-07-13 05:04
---
There's certainly no reason not to fix this on release branches.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
--- Comment #9 from pault at gcc dot gnu dot org 2006-07-13 05:07 ---
Subject: Bug 28174
Author: pault
Date: Thu Jul 13 05:07:35 2006
New Revision: 115410
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115410
Log:
2006-07-13 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from pault at gcc dot gnu dot org 2006-07-13 05:07 ---
Subject: Bug 25097
Author: pault
Date: Thu Jul 13 05:07:35 2006
New Revision: 115410
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115410
Log:
2006-07-13 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2006-07-13 05:07 ---
Subject: Bug 20903
Author: pault
Date: Thu Jul 13 05:07:35 2006
New Revision: 115410
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115410
Log:
2006-07-13 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-13 05:37 ---
Note a related testcase is:
#define vector __attribute__((vector_size(16)))
float f(vector float t)
{
return *(float*)(&t);
}
Which is only mentioned here in get_alias_set in the GCC sources as being not
violating
-std=c89 doesn't warn about gcc's "?:" extension
Environment:
System: Linux rho 2.6.15-1-amd64-k8 #2 Tue Mar 7 06:53:26 UTC 2006 x86_64
GNU/Linux
Architecture: x86_64
host: x86_64-unknown-linux-gnu
build: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
configured with: /mirror
--- Comment #6 from fengwang at gcc dot gnu dot org 2006-07-13 06:34
---
Fixed on trunk and 4.1
--
fengwang at gcc dot gnu dot org changed:
What|Removed |Added
101 - 118 of 118 matches
Mail list logo
