[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2009-06-29 Thread ubizjak at gmail dot com
--- Comment #8 from ubizjak at gmail dot com 2009-06-29 08:47 --- (In reply to comment #7) OTOH, doing integer arithmetics on 64bit _image_ of FP value has questionable usability, so the motivation to fix this PR is proportionally low... So, wontfix. -- ubizjak at gmail dot com

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2009-06-17 Thread ubizjak at gmail dot com
--- Comment #7 from ubizjak at gmail dot com 2009-06-17 09:18 --- See Comment #2! I tried to enhance ix86_secondary_reload target macro to return XMM intermediate reg with movdi_to_sse handler for DImode - DFmode moves. However, handling of this macro has plenty of FIXMEs, and I was

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2009-06-16 Thread dominiq at lps dot ens dot fr
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-16 20:30 --- I have forgotten this one! This is not darwin-specific, I also see it happening on x86_64-linux. And what's more, the output changes between -m32 and -m64. This is probably related to the extra precision for

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2009-06-16 Thread kargl at gcc dot gnu dot org
--- Comment #6 from kargl at gcc dot gnu dot org 2009-06-16 21:02 --- (In reply to comment #5) The code is invalid Fortran, so gfortran is not required to give any sensible output. You know that it is not relevant for this pr!-( would the following make you happier?) It most

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2009-06-15 Thread fxcoudert at gcc dot gnu dot org
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-15 18:32 --- This is not darwin-specific, I also see it happening on x86_64-linux. And what's more, the output changes between -m32 and -m64. $ cat u.f90 integer(8), parameter :: l = z'5fe6eb3be000' integer, parameter

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2009-06-15 Thread kargl at gcc dot gnu dot org
--- Comment #4 from kargl at gcc dot gnu dot org 2009-06-15 18:44 --- (In reply to comment #3) This is not darwin-specific, I also see it happening on x86_64-linux. And what's more, the output changes between -m32 and -m64. The code is invalid Fortran, so gfortran is not required

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2008-05-15 Thread rguenth at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-15 09:06 --- First without -ffast-math the phiopt doesn't recognize the MAX_EXPR (see PR36190), second t.f90:24: note: not vectorized: number of iterations cannot be computed. t.f90:24: note: bad loop form. which is the

[Bug target/36241] Executable compiled with -m64 almost three times faster than the one compiled with -m32 on Core2Duo

2008-05-15 Thread ubizjak at gmail dot com
--- Comment #2 from ubizjak at gmail dot com 2008-05-15 09:21 --- This regression is due to store forwarding penalty: ... movl%esi, -408(%ebp) movl%edi, -404(%ebp) fldl-408(%ebp) ... --