--- Comment #29 from dominiq at lps dot ens dot fr 2009-09-01 09:37 ---
Does anyone understand why commenting a write can change crtl-maybe_hot_insn_p
from 1 to 0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
--- Comment #24 from dominiq at lps dot ens dot fr 2009-08-31 13:06 ---
(In reply to comment #23)
Aren't these compile lines identical?
Apparently no, -funsafe-math-optimizations turns on optimization(s) that cannot
be undone by
-fno-signed-zeros -fno-trapping-math
--- Comment #25 from dominiq at lps dot ens dot fr 2009-08-31 15:04 ---
If I compare the results of -fdump-tree-original for the first 2 cases of
comment #21 I get:
[ibook-dhum] test/dbg_air% gfc -m64 -O2 -funsafe-math-optimizations
-fdump-tree-original air_db.f90
[ibook-dhum]
--- Comment #26 from jv244 at cam dot ac dot uk 2009-08-31 15:20 ---
(In reply to comment #25)
- if (npx[(integer(kind=8)) i + -1] + 1
j)
+ if (NON_LVALUE_EXPR
npx[(integer(kind=8)) i + -1] = j) where
--- Comment #27 from rguenther at suse dot de 2009-08-31 15:23 ---
Subject: Re: Time increase for the Polyhedron test
air.f90 due to bad optimization
On Mon, 31 Aug 2009, jv244 at cam dot ac dot uk wrote:
--- Comment #26 from jv244 at cam dot ac dot uk 2009-08-31 15:20 ---
--- Comment #20 from dominiq at lps dot ens dot fr 2009-08-28 07:19 ---
It it helps, I get for the reduced test with the line 94:
[ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations
-fno-signed-zeros -fno-trapping-math -fno-associative-math -fno-reciprocal-math
air_db.f90
--- Comment #21 from dominiq at lps dot ens dot fr 2009-08-28 12:01 ---
And finally the winner is -fstrict-overflow!
[ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations air_db.f90
[ibook-dhum] lin/test% time a.out /dev/null
6.472u 0.020s 0:06.50 99.8% 0+0k 0+2io 0pf+0w
--- Comment #22 from dominiq at lps dot ens dot fr 2009-08-28 12:23 ---
For the original air.f90 I get:
[ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations
-fno-strict-overflow air.f90
[ibook-dhum] lin/test% time a.out /dev/null
9.572u 0.055s 0:09.66 99.5% 0+0k 0+9io
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2009-08-28
13:36 ---
(In reply to comment #20)
It it helps, I get for the reduced test with the line 94:
[ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations
-fno-signed-zeros -fno-trapping-math
--- Comment #17 from dominiq at lps dot ens dot fr 2009-08-27 21:59 ---
Created an attachment (id=18439)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18439action=view)
reduced test without any subroutine
I have attached a reduced test without any subroutine. It requires the same
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-08-28
01:09 ---
Why don't you go back to the original test case and see which component of
-funsafe-math-optimizations...
-fno-signed-zeros -fno-trapping-math -fassociative-math -freciprocal-math
is actually causing
--- Comment #19 from dominiq at lps dot ens dot fr 2009-08-28 05:39 ---
Why don't you go back to the original test case and see which component of
-funsafe-math-optimizations...
-fno-signed-zeros -fno-trapping-math -fassociative-math -freciprocal-math
is actually causing the
--- Comment #10 from dominiq at lps dot ens dot fr 2009-08-25 12:01 ---
I see a similar slowdown with the patch in ...
I have again forgotten to say that I saw the slowdown without the -fwhole-file
option.
I have changed the summary to reflect that.
--
dominiq at lps dot ens dot
--- Comment #16 from dominiq at lps dot ens dot fr 2009-08-25 21:25 ---
After some discussion on IRC with Tobias Schlüter, it seems that the problem
comes from bad optimizations that are broken by chance with the original code.
Commenting line 139:
WRITE (6,*) i , spx(i) ,
14 matches
Mail list logo
