http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #22 from Sebastian Pop 2011-02-02
15:52:26 UTC ---
Author: spop
Date: Wed Feb 2 15:52:21 2011
New Revision: 169531
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169531
Log:
Fix PR40979 and PR47044: after LIM call copy_prop a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #21 from Sebastian Pop 2011-02-01
20:51:31 UTC ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00070.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #20 from Jack Howarth 2011-02-01
20:15:49 UTC ---
FYI, the patches in Comment 14 and 17 when also used with the patch...
Index: opts.c
===
--- opts.c (revision 1673
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #19 from Dominique d'Humieres
2011-02-01 17:40:17 UTC ---
> That made the loop vectorizable.
Confirmed on top of the patch in comment #14.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #18 from sebpop at gmail dot com
2011-02-01 17:22:06 UTC ---
On Tue, Feb 1, 2011 at 11:15, rguenth at gcc dot gnu.org
wrote:
> I'd suggest
>
> NEXT_PASS (pass_graphite);
> {
> struct opt_pass **p = &p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #16 from sebpop at gmail dot com
2011-02-01 16:59:03 UTC ---
> It's unfortunate that graphite inserts arrays of size 1 instead of scalar
> (memory) vars.
That could be easily fixed.
graphite can also use the original data reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #17 from Richard Guenther 2011-02-01
17:04:38 UTC ---
(In reply to comment #15)
> The vectorizer does not apply because it does not match the canonical
> form of a reduction: here is the reduction after graphite-identity:
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #15 from Sebastian Pop 2011-02-01
16:46:54 UTC ---
The vectorizer does not apply because it does not match the canonical
form of a reduction: here is the reduction after graphite-identity:
# l12__lsm.18_179 = PHI
S1:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #14 from Richard Guenther 2011-02-01
11:45:44 UTC ---
Noting that pass_graphite_transforms lacks any verifier calls, the following
would enable the cleanup (in case scalar vars would have been used).
Index: gcc/tree-ssa-loop.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #13 from Richard Guenther 2011-02-01
11:35:08 UTC ---
It's unfortunate that graphite inserts arrays of size 1 instead of scalar
(memory) vars. Otherwise update-address-taken would just re-write those
into SSA after going out-of-graph
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #12 from Dominique d'Humieres
2011-01-31 18:46:23 UTC ---
> I looked at how to improve translate_scalar_reduction_to_array in
> order to avoid the creation of the temporary array, but it seems to be
> difficult as the result is writte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #11 from Sebastian Pop 2011-01-31
18:12:38 UTC ---
Here is a reduced testcase from induct.f90 for the first loop
not vectorized with -fgraphite-identity:
module mqc_m
integer, parameter, private :: longreal = selected_real_kind(15,90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #10 from Jack Howarth 2011-01-26
14:20:18 UTC ---
(In reply to comment #9)
> This pr is not fixed at revision 169261 (gfc). AFAIU -ftree-loop-linear is now
> implemented through graphite. This leads to a sort of regression with respec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #9 from Dominique d'Humieres 2011-01-26
10:23:12 UTC ---
This pr is not fixed at revision 169261 (gfc). AFAIU -ftree-loop-linear is now
implemented through graphite. This leads to a sort of regression with respect
to revision 169227(g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
Sebastian Pop changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
--- Comment #7 from dominiq at lps dot ens dot fr 2010-03-15 14:21 ---
See also pr43359.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-03-10
01:57 ---
The code being degraded by -fgraphite-identity (when using -ffast-math
-funroll-loops -O3) is in the mqr_m and mqc_m modules. The exact distribution
of performance loss in execution time for the induct benc
--- Comment #4 from dominiq at lps dot ens dot fr 2010-02-25 15:23 ---
At revision 156693 or higher, the miscompilation with -floop-interchange
reported in comment #3 is gone. As a consequence the corresponding execution
time is now the same as when compiled with -fgraphite-identity.
T
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|spop at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- Comment #3 from dominiq at lps dot ens dot fr 2009-08-14 11:59 ---
> Interestingly, this benchmark is also the one that shows the best improvement
> from -floop-interchange...
I also see that ~20s versus ~34s, however comparing the outputs:
Maximum wand/quad abs rel mutual inducta
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2009-08-13
02:25 ---
Interestingly, this benchmark is also the one that shows the best improvement
from -floop-interchange...
Compile Command : gfortran -ffast-math -funroll-loops -msse3 -O3 %n.f90 -o %n
Benchmarks : indu
--- Comment #1 from spop at gcc dot gnu dot org 2009-08-12 14:58 ---
Still fails on my machine, on rev150694.
~/gcc/svn/trunk/usr/bin/gfortran -ffast-math -funroll-loops -msse3 -O3
induct.f90 -o induct
time ./induct
real0m16.596s
user0m16.393s
sys 0m0.076s
~/gcc/svn/trunk/u
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org
|dot org
24 matches
Mail list logo
