On 06/29/2011 12:35 PM, Sebastian Pop wrote:
2011-06-29  Sebastian Pop<sebastian....@amd.com>

        * graphite-clast-to-gimple.c (precision_for_value): Removed.
        (precision_for_interval): Removed.
        (gcc_type_for_interval): Use mpz_sizeinbase.
-/* Return a type that could represent the integer value VAL.  */
+/* Return a type that could represent the values between LOW and UP.
+   The value of LOW can be bigger than UP.  */

  static tree
  gcc_type_for_interval (mpz_t low, mpz_t up)
  {

Hi Sebastian,

why do we continue to call low 'low' and up 'up', if we actually just have two values v1 and v2 where we do not know which one is larger? I think this wrong and probably comes because we pass the lower loop bound to val_one and the upper loop bound to val_two.

What about:

+/* Return a type that could represent all values between VAL_ONE and
+   VAL_TWO including VAL_ONE and VAL_TWO itself.  There is no
+   constraint on which of the two values is larger.  */

  static tree
- gcc_type_for_interval (mpz_t low, mpz_t up)
+ gcc_type_for_interval (mpz_t val_one, mpz_t val_two)
   {

-  bool unsigned_p = true;
-  int precision, prec_up, prec_int;
+  bool unsigned_p;
    tree type;
    enum machine_mode mode;
-
-  gcc_assert (mpz_cmp (low, up)<= 0);
-
-  prec_up = precision_for_value (up);
-  prec_int = precision_for_interval (low, up);
-  precision = MAX (prec_up, prec_int);
+  int precision = MAX (mpz_sizeinbase (low, 2),
+                      mpz_sizeinbase (up, 2));

    if (precision>  BITS_PER_WORD)
      {
@@ -452,14 +397,10 @@ gcc_type_for_interval (mpz_t low, mpz_t up)
        return integer_type_node;
      }

-  if (mpz_sgn (low)<= 0)
-    unsigned_p = false;
-
-  else if (precision<  BITS_PER_WORD)
-    {
-      unsigned_p = false;
-      precision++;
-    }
+  if (mpz_cmp (low, up)<= 0)
+    unsigned_p = (mpz_sgn (low)>= 0);
+  else
+    unsigned_p = (mpz_sgn (up)>= 0);

What about?

       unsigned_p = value_min(low, up) >= 0;

(You need to move the implementation of value_min to this patch)


    mode = smallest_mode_for_size (precision, MODE_INT);
    precision = GET_MODE_PRECISION (mode);

In general the new implementation looks a lot more elegant as the old one. What was the problem with the old one? That low could be larger than up and that the calculation in precision_for_interval was incorrect (or at least not understandable for me)?

The rest of the patch looks good.

Cheers
Tobi

Reply via email to