This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[lno] Fix ia64 bootstrap


Hello,

with this patch lno-branch bootstraps with -ftree-loop-optimize on ia64
(finally). Unfortunately it also prevents strength reduction on
architectures where sizeof (int) < sizeof (void *); I am working on
that.

Zdenek

Index: ChangeLog.lno
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Attic/ChangeLog.lno,v
retrieving revision 1.1.2.111
retrieving revision 1.1.2.112
diff -c -3 -p -r1.1.2.111 -r1.1.2.112
*** ChangeLog.lno	31 Mar 2004 14:16:47 -0000	1.1.2.111
--- ChangeLog.lno	31 Mar 2004 18:41:33 -0000	1.1.2.112
***************
*** 1,3 ****
--- 1,8 ----
+ 2004-03-31  Zdenek Dvorak  <rakdver@atrey.karlin.mff.cuni.cz>
+ 
+ 	* tree-ssa-loop-ivopts.c (idx_find_step): Prevent misscompilation
+ 	in case the index overflows.
+ 
  2004-03-31  Zdenek Dvorak  <rakdver@atrey.karlin.mff.cuni.cz>,
  	    Dorit Naishlos <DORIT@il.ibm.com>
  
Index: tree-ssa-loop-ivopts.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Attic/tree-ssa-loop-ivopts.c,v
retrieving revision 1.1.2.21
retrieving revision 1.1.2.22
diff -c -3 -p -r1.1.2.21 -r1.1.2.22
*** tree-ssa-loop-ivopts.c	30 Mar 2004 13:27:12 -0000	1.1.2.21
--- tree-ssa-loop-ivopts.c	31 Mar 2004 18:41:33 -0000	1.1.2.22
*************** idx_find_step (tree base, tree *idx, voi
*** 1986,1992 ****
  {
    tree *step_p = data;
    struct iv *iv;
!   tree step, type;
    
    if (TREE_CODE (*idx) != SSA_NAME)
      return true;
--- 1986,1992 ----
  {
    tree *step_p = data;
    struct iv *iv;
!   tree step, type, iv_type;
    
    if (TREE_CODE (*idx) != SSA_NAME)
      return true;
*************** idx_find_step (tree base, tree *idx, voi
*** 2000,2018 ****
    if (!iv->step)
      return true;
  
    if (base)
      {
-       step = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (base)));
        type = array2ptr (TREE_TYPE (base));
      }
    else
      {
-       /* The step for pointer arithmetics already is 1 byte.  */
-       step = integer_one_node;
        type = TREE_TYPE (*idx);
      }
  
!   step = EXEC_BINARY (MULT_EXPR, type, step, iv->step);
  
    if (!*step_p)
      *step_p = step;
--- 2000,2044 ----
    if (!iv->step)
      return true;
  
+   iv_type = TREE_TYPE (iv->base);
    if (base)
      {
        type = array2ptr (TREE_TYPE (base));
+       step = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (base)));
      }
    else
      {
        type = TREE_TYPE (*idx);
+       /* The step for pointer arithmetics already is 1 byte.  */
+       step = convert (type, integer_one_node);
+     }
+ 
+   if (TYPE_PRECISION (iv_type) < TYPE_PRECISION (type))
+     {
+       /* The index might wrap.  */
+ 
+       /* TODO -- this is especially bad for targets where
+ 	 sizeof (int) < sizeof (void *).  We should at least:
+ 
+ 	 1) Use the number of iterations of the current loop to prove
+ 	    that the index cannot wrap.
+ 	 2) Record whether only a signed arithmetics is used during computation
+ 	    of the index (behavior of overflows during signed arithmetics is
+ 	    undefined, so we may assume that it does not happen). Problems:
+ 	    * The optimizations may create overflowing signed arithmetics.
+ 	    * And they may also remove the no-op casts used to make the
+ 	      behavior of overflows defined.
+ 	 3) Use array bounds when known (if the memory is accessed at each
+ 	    iteration, we know the index cannot come out of them).  Better,
+ 	    use this to estimate the number of iterations of the loop.
+ 	 4) If all indices are of the same type, we can also rewrite the
+ 	    access as &base + (extend) (step * i), and optimize the step * i
+ 	    part separately.  */
+       return false;
      }
  
!   step = EXEC_BINARY (MULT_EXPR, type, step,
! 		      convert (type, iv->step));
  
    if (!*step_p)
      *step_p = step;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]