Message ID | 4DF9F1DC.8080306@codesourcery.com |
---|---|
State | New |
Headers | show |
Hi, > diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c (working copy) > --- gcc/tree-ssa-loop-niter.c (working copy) > +++ gcc/tree-ssa-loop-niter.c (working copy) > @@ -2875,6 +2875,16 @@ > low = lower_bound_in_type (type, type); > high = upper_bound_in_type (type, type); > > + /* In C, pointer arithmetic p + 1 cannot use a NULL pointer, and p - 1 cannot > + produce a NULL pointer. The contrary would mean NULL points to an object, > + while NULL is supposed to compare unequal with the address of all objects. > + Furthermore, p + 1 cannot produce a NULL pointer and p - 1 cannot use a > + NULL pointer since that would mean wrapping, which we assume here not to > + happen. So, we can exclude NULL from the valid range of pointer > + arithmetic. */ > + if (int_cst_value (low) == 0) > + low = build_int_cstu (TREE_TYPE (low), TYPE_ALIGN_UNIT (TREE_TYPE (type))); > + > record_nonwrapping_iv (loop, base, step, stmt, low, high, false, true); > } OK, Zdenek
On Thu, Jun 16, 2011 at 5:24 PM, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote: > Hi, > >> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c (working copy) >> --- gcc/tree-ssa-loop-niter.c (working copy) >> +++ gcc/tree-ssa-loop-niter.c (working copy) >> @@ -2875,6 +2875,16 @@ >> low = lower_bound_in_type (type, type); >> high = upper_bound_in_type (type, type); >> >> + /* In C, pointer arithmetic p + 1 cannot use a NULL pointer, and p - 1 cannot >> + produce a NULL pointer. The contrary would mean NULL points to an object, >> + while NULL is supposed to compare unequal with the address of all objects. >> + Furthermore, p + 1 cannot produce a NULL pointer and p - 1 cannot use a >> + NULL pointer since that would mean wrapping, which we assume here not to >> + happen. So, we can exclude NULL from the valid range of pointer >> + arithmetic. */ >> + if (int_cst_value (low) == 0) >> + low = build_int_cstu (TREE_TYPE (low), TYPE_ALIGN_UNIT (TREE_TYPE (type))); >> + >> record_nonwrapping_iv (loop, base, step, stmt, low, high, false, true); >> } > > OK, I think this is only valid for !flag_delete_null_pointer_checks, on architectures where that isn't the default we have to assume that NULL may point to an object. Richard. > Zdenek >
> >> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c (working copy) > >> --- gcc/tree-ssa-loop-niter.c (working copy) > >> +++ gcc/tree-ssa-loop-niter.c (working copy) > >> @@ -2875,6 +2875,16 @@ > >> low = lower_bound_in_type (type, type); > >> high = upper_bound_in_type (type, type); > >> > >> + /* In C, pointer arithmetic p + 1 cannot use a NULL pointer, and p - 1 cannot > >> + produce a NULL pointer. The contrary would mean NULL points to an object, > >> + while NULL is supposed to compare unequal with the address of all objects. > >> + Furthermore, p + 1 cannot produce a NULL pointer and p - 1 cannot use a > >> + NULL pointer since that would mean wrapping, which we assume here not to > >> + happen. So, we can exclude NULL from the valid range of pointer > >> + arithmetic. */ > >> + if (int_cst_value (low) == 0) > >> + low = build_int_cstu (TREE_TYPE (low), TYPE_ALIGN_UNIT (TREE_TYPE (type))); > >> + > >> record_nonwrapping_iv (loop, base, step, stmt, low, high, false, true); > >> } > > > > OK, > > I think this is only valid for !flag_delete_null_pointer_checks, on > architectures where that isn't the default we have to assume that > NULL may point to an object. agreed. Thanks for the correction. Zdenek
On 06/16/2011 05:42 PM, Zdenek Dvorak wrote: >>>> diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c (working copy) >>>> --- gcc/tree-ssa-loop-niter.c (working copy) >>>> +++ gcc/tree-ssa-loop-niter.c (working copy) >>>> @@ -2875,6 +2875,16 @@ >>>> low = lower_bound_in_type (type, type); >>>> high = upper_bound_in_type (type, type); >>>> >>>> + /* In C, pointer arithmetic p + 1 cannot use a NULL pointer, and p - 1 cannot >>>> + produce a NULL pointer. The contrary would mean NULL points to an object, >>>> + while NULL is supposed to compare unequal with the address of all objects. >>>> + Furthermore, p + 1 cannot produce a NULL pointer and p - 1 cannot use a >>>> + NULL pointer since that would mean wrapping, which we assume here not to >>>> + happen. So, we can exclude NULL from the valid range of pointer >>>> + arithmetic. */ >>>> + if (int_cst_value (low) == 0) >>>> + low = build_int_cstu (TREE_TYPE (low), TYPE_ALIGN_UNIT (TREE_TYPE (type))); >>>> + >>>> record_nonwrapping_iv (loop, base, step, stmt, low, high, false, true); >>>> } >>> >>> OK, >> >> I think this is only valid for !flag_delete_null_pointer_checks, on >> architectures where that isn't the default we have to assume that >> NULL may point to an object. > > agreed. Thanks for the correction. > > Zdenek committed with test for flag_delete_null_pointer_checks added. Thanks, - Tom
diff -u gcc/tree-ssa-loop-niter.c (working copy) gcc/tree-ssa-loop-niter.c (working copy) --- gcc/tree-ssa-loop-niter.c (working copy) +++ gcc/tree-ssa-loop-niter.c (working copy) @@ -2875,6 +2875,16 @@ low = lower_bound_in_type (type, type); high = upper_bound_in_type (type, type); + /* In C, pointer arithmetic p + 1 cannot use a NULL pointer, and p - 1 cannot + produce a NULL pointer. The contrary would mean NULL points to an object, + while NULL is supposed to compare unequal with the address of all objects. + Furthermore, p + 1 cannot produce a NULL pointer and p - 1 cannot use a + NULL pointer since that would mean wrapping, which we assume here not to + happen. So, we can exclude NULL from the valid range of pointer + arithmetic. */ + if (int_cst_value (low) == 0) + low = build_int_cstu (TREE_TYPE (low), TYPE_ALIGN_UNIT (TREE_TYPE (type))); + record_nonwrapping_iv (loop, base, step, stmt, low, high, false, true); }