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]

Re: [patch] for PRs 27639 and 26719


Hello,

> Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> writes:
> 
> > > > I disagree: IVOPTs should preserve the semantics of subtypes, that is to say 
> > > > the arithmetics operations are performed in the base type and the result is 
> > > > casted to the subtype.  IOW, it should not generate IVs in subtypes.  IIUC 
> > > > it's Jeff's position too: http://gcc.gnu.org/ml/gcc/2006-02/msg00590.html
> > > 
> > > OK, I was not aware of this (I was cced in the mail, but with a typo in
> > > the address).  I will prepare the patch to fix the problem.
> > 
> > here is the patch I'd consider correct.  I still need to test it (I
> > forgot to include ada in regtesting this time).
> 
> I know you didn't submit this patch officially yet, but here are a few
> comments.

here is the patch with the changed comments and renamed function.  I
have bootstrapped & regtested it on i686.  Ok?

Zdenek

	* tree-chrec.c (avoid_arithmetics_in_type_p): New.
	(convert_affine_scev, chrec_convert_aggressive): Use
	avoid_arithmetics_in_type_p.  Do not check for the subtypes
	separately.

Index: tree-chrec.c
===================================================================
*** tree-chrec.c	(revision 115221)
--- tree-chrec.c	(working copy)
*************** nb_vars_in_chrec (tree chrec)
*** 1096,1101 ****
--- 1096,1116 ----
      }
  }
  
+ /* Returns true if TYPE is a type in that we cannot directly perform
+    arithmetics, even though it is a scalar type.  */
+ 
+ static bool
+ avoid_arithmetics_in_type_p (tree type)
+ {
+   /* Ada frontend uses subtypes -- an arithmetic cannot be directly performed
+      in the subtype, but a base type must be used, and the result then can
+      be casted to the subtype.  */
+   if (TREE_CODE (type) == INTEGER_TYPE && TREE_TYPE (type) != NULL_TREE)
+     return true;
+ 
+   return false;
+ }
+ 
  static tree chrec_convert_1 (tree, tree, tree, bool);
  
  /* Converts BASE and STEP of affine scev to TYPE.  LOOP is the loop whose iv
*************** convert_affine_scev (struct loop *loop, 
*** 1116,1121 ****
--- 1131,1140 ----
    bool must_check_src_overflow, must_check_rslt_overflow;
    tree new_base, new_step;
  
+   /* If we cannot perform arithmetic in TYPE, avoid creating an scev.  */
+   if (avoid_arithmetics_in_type_p (type))
+     return false;
+ 
    /* In general,
       (TYPE) (BASE + STEP * i) = (TYPE) BASE + (TYPE -- sign extend) STEP * i,
       but we must check some assumptions.
*************** chrec_convert_aggressive (tree type, tre
*** 1305,1310 ****
--- 1324,1333 ----
    if (TYPE_PRECISION (type) > TYPE_PRECISION (inner_type))
      return NULL_TREE;
  
+   /* If we cannot perform arithmetic in TYPE, avoid creating an scev.  */
+   if (avoid_arithmetics_in_type_p (type))
+     return false;
+ 
    left = CHREC_LEFT (chrec);
    right = CHREC_RIGHT (chrec);
    lc = chrec_convert_aggressive (type, left);
*************** chrec_convert_aggressive (tree type, tre
*** 1313,1339 ****
    rc = chrec_convert_aggressive (type, right);
    if (!rc)
      rc = chrec_convert (type, right, NULL_TREE);
! 
!   /* Ada creates sub-types where TYPE_MIN_VALUE/TYPE_MAX_VALUE do not
!      cover the entire range of values allowed by TYPE_PRECISION.
! 
!      We do not want to optimize away conversions to such types.  Long
!      term I'd rather see the Ada front-end fixed.  */
!   if (INTEGRAL_TYPE_P (type))
!     {
!       tree t;
! 
!       t = upper_bound_in_type (type, inner_type);
!       if (! TYPE_MAX_VALUE (type)
! 	  || ! operand_equal_p (TYPE_MAX_VALUE (type), t, 0))
! 	return NULL_TREE;
! 
!       t = lower_bound_in_type (type, inner_type);
!       if (! TYPE_MIN_VALUE (type)
! 	  || ! operand_equal_p (TYPE_MIN_VALUE (type), t, 0))
! 	return NULL_TREE;
!     }
!   
    return build_polynomial_chrec (CHREC_VARIABLE (chrec), lc, rc);
  }
  
--- 1336,1342 ----
    rc = chrec_convert_aggressive (type, right);
    if (!rc)
      rc = chrec_convert (type, right, NULL_TREE);
!  
    return build_polynomial_chrec (CHREC_VARIABLE (chrec), lc, rc);
  }
  


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