Mike Stump wrote:
On Apr 20, 2007, at 6:42 PM, Robert Dewar wrote:
One possibility would be to have a -Om switch (or whatever) that
says "do all optimizations for this machine that help".
Ick, gross. No.
Well OK, Ick, but below you recommend removingf the overly
pedantic rule. I agree with
Kenneth Hoste wrote:
I'm not sure what 'tests' mean here... Are test cases being extracted
from the SPEC CPU2006 sources? Or are you refering to the validity tests
of the SPEC framework itself (to check whether the output generated by
some binary conforms with their reference output)?
The cla
Tom Dickens wrote:
../gcc/configure -enable-languages=c,c++,fortran.
make[1]: Leaving directory `/cygdrive/c/gcc-4.1.2/obj'
You ran the wrong configure script. You must always run the toplevel
configure script, not the one inside the gcc directory.
So instead of doing
cd gcc-4.1.2
mkdi
H. J. Lu wrote:
__builtin_ia32_vec_set_v2di will be expanded to
[(set (match_operand:V2DI 0 "register_operand" "=x")
(vec_merge:V2DI
(vec_duplicate:V2DI
(match_operand:DI 2 "nonimmediate_operand" "rm"))
(match_operand:V2DI 1 "register_operand" "0")
On Fri, 2007-04-20 at 19:28 -0400, Robert Dewar wrote:
> Steve Ellcey wrote:
>
> > This seems unfortunate. I was hoping I might be able to turn on loop
> > unrolling for IA64 at -O2 to improve performance. I have only started
> > looking into this idea but it seems to help performance quite a bi
On Apr 21, 2007, at 3:12 AM, Robert Dewar wrote:
So, Mike, my question is, assuming we cannot remove the rule what
do you want to do
I think in the end, each situation is different and we have to find
the best solution for each situation. So, in that siprit, let's open
a discussion for th
I've decided to try to contribute modifications to the the C code
that is generated by the Gambit Scheme->C compiler so that (a) it
doesn't have any aliasing violations and (b) more aliasing
distinctions can be made (the car and cdr of a pair don't overlap
with the entries of a vector, etc.
On 4/21/07, Bradley Lucier <[EMAIL PROTECTED]> wrote:
I didn't think that adding aliasing information could lead to worse
code. So I'm wondering how to use that aliasing information more
effectively to get better code.
What aliasing information could do is allow an optimization pass cause
regi
We still have some lno bits in our tree. We tried to remove them and
found:
gzip +0.5%
vpr -0.4%
gcc -3.2%
mcf -0.3%
crafty +0.2%
parser +0.2%
perlbmk -2.2%
gap +0.2%
vortex -0.1%
bzip2 +1.9%
twolf -0.7%
on x86 (probably a core2 duo) in our 4.2 tree (with the rest of our
local patches). -3
On 4/21/07, Mike Stump <[EMAIL PROTECTED]> wrote:
We still have some lno bits in our tree. We tried to remove them and
found:
Of all the LNO bits, the last major bits seems to be the below bit.
I don't even know if it is responsible for the benefit we see. I
thought I'd mention it, as a 2-3% wi
10 matches
Mail list logo
