[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2010-09-08 Thread dominiq at lps dot ens dot fr 


--- Comment #8 from dominiq at lps dot ens dot fr  2010-09-08 17:49 ---
One of the first thing taught in fortran is that the loop ordering in the test
in comment #0 is bad.

If the loops are interchanged (as they should) the code vectorize. Is not
-floop-interchange supposed to do that if graphite is enabled (actually it does
not do it or if it does, it does not allow the code to be vectorized)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2009-01-27 Thread dorit at gcc dot gnu dot org 


--- Comment #7 from dorit at gcc dot gnu dot org  2009-01-27 12:46 ---
related testcase/PR: PR37021 
and related discussion: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01322.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2007-10-31 Thread sebpop at gmail dot com 


--- Comment #5 from sebpop at gmail dot com  2007-10-31 23:43 ---
Subject: Re:  Failing to represent the stride (with array) of a dataref when it
is not a constant

  Making us return symbolic stride would not be hard.  The problem is that 
  data
  dependence analysis would fail anyway,


True, and the vectorizer has also to be fixed to not consider
INTEGER_CST strides only.

 sometimes (not in this testcases) there won't be a need for dependence testing
 - e.g. a reduction computation where there are no stores, or initialization
 with a constant (i.e. a store and no loads), so there's already a value in
 doing this.


This patch would let symbolic non integer_cst steps to be computed,
and stored in DR_STEP:

Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 129797)
+++ tree-data-ref.c (working copy)
@@ -657,7 +657,7 @@ dr_analyze_innermost (struct data_refere
   offset_iv.base = ssize_int (0);
   offset_iv.step = ssize_int (0);
 }
-  else if (!simple_iv (loop, stmt, poffset, offset_iv, false))
+  else if (!simple_iv (loop, stmt, poffset, offset_iv, true))
 {
   if (dump_file  (dump_flags  TDF_DETAILS))
fprintf (dump_file, failed: evolution of offset is not affine.\n);


but the problem is that in the vectorizer, DR_STEP has to be an
INTEGER_CST: for instance,

  step = TREE_INT_CST_LOW (DR_STEP (dra));
...
  || tree_int_cst_compare (DR_STEP (dra), DR_STEP (drb)))

and plenty of other places will ICE if we feed them with symbolic
strides.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2007-10-31 Thread dorit at gcc dot gnu dot org 


--- Comment #6 from dorit at gcc dot gnu dot org  2007-11-01 00:55 ---
thanks!

 but the problem is that in the vectorizer, DR_STEP has to be an
 INTEGER_CST: for instance,
   step = TREE_INT_CST_LOW (DR_STEP (dra));
 ...
   || tree_int_cst_compare (DR_STEP (dra), DR_STEP (drb)))
 and plenty of other places will ICE if we feed them with symbolic
 strides.

This can be fixed. I'll try to look into that.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2007-08-31 Thread spop at gcc dot gnu dot org 


--- Comment #4 from spop at gcc dot gnu dot org  2007-08-31 14:19 ---
*** Bug 33246 has been marked as a duplicate of this bug. ***


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2007-08-20 Thread rakdver at kam dot mff dot cuni dot cz 


--- Comment #3 from rakdver at kam dot mff dot cuni dot cz  2007-08-20 
12:10 ---
Subject: Re:  Failing to represent the stride (with array) of a dataref when it
is not a constant

 --- Comment #2 from dorit at gcc dot gnu dot org  2007-08-20 05:55 ---
  Making us return symbolic stride would not be hard.  The problem is that 
  data
  dependence analysis would fail anyway, 
 
 sometimes (not in this testcases) there won't be a need for dependence testing
 - e.g. a reduction computation where there are no stores, or initialization
 with a constant (i.e. a store and no loads), so there's already a value in
 doing this.
 
  since we cannot tell whether n is zero.
 
 can we do the data-dependence analysis conditioned on a maybe_zero (like the
 number-of-iterations analysis)?

possibly a more useful solution would be to teach fortran frontend to use
multidimensional arrays, instead of flattening them to one-dimensional
ones (however, this is also a fairly nontrivial task).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2007-08-19 Thread rakdver at gcc dot gnu dot org 


--- Comment #1 from rakdver at gcc dot gnu dot org  2007-08-19 20:08 ---
(In reply to comment #0)
 In the following testcase:
 
 subroutine sub(aa,bb,n,m)
   implicit none
   integer, intent(in) :: n,m
   real, intent(inout) :: aa(n,m)
   real, intent(in):: bb(n,m)
   integer :: i,j
  do i = 1,m
 do j= 2,n
   aa(i,j)= aa(i,j-1)+bb(i,j-1)
 enddo
   enddo
 end subroutine
 end
 
 The stride of the accesses in the inner-loop is a parameter (m is not a
 compile-time known constant). As a result the data dataref analyzer reports:
 
 failed: evolution of offset is not affine
 ...
 base_address:
 offset from base address:
 constant offset from base address:
 step:
 aligned to:
 base_object: (*aa_54(D))[0]
 symbol tag: SMT.25
 
 
 Any chance that the dataref analysis can return an (invariant) expression in
 step, so that further analysis could continue? (for example, the access in
 the outer-loop is consecutive, so if we had an expression to represent the
 inner-loop stride, we could vectorize the outer-loop).

Making us return symbolic stride would not be hard.  The problem is that data
dependence analysis would fail anyway, since we cannot tell whether n is zero.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113

[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant

2007-08-19 Thread dorit at gcc dot gnu dot org 


--- Comment #2 from dorit at gcc dot gnu dot org  2007-08-20 05:55 ---
 Making us return symbolic stride would not be hard.  The problem is that data
 dependence analysis would fail anyway, 

sometimes (not in this testcases) there won't be a need for dependence testing
- e.g. a reduction computation where there are no stores, or initialization
with a constant (i.e. a store and no loads), so there's already a value in
doing this.

 since we cannot tell whether n is zero.

can we do the data-dependence analysis conditioned on a maybe_zero (like the
number-of-iterations analysis)? (by the way, I was told that ifort vectorizes
this. I think we'd need loop reversal to vectorize the inner-loop though. on
top of overcoming the unknown-stride issue in the DR and DDR analysis)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113