On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez <al...@redhat.com> wrote:
>
> This patch cleans up the various contains, may_contain, and
> value_inside_range variants we have throughout, in favor of one--
> contains_p. There should be no changes in functionality.
>
> I have added a note to range_includes_zero_p, perhaps as a personal
> question than anything else. This function was/is returning true for
> UNDEFINED. From a semantic sense, that doesn't make sense. UNDEFINED
> is really the empty set. Is the functionality wrong, or should we call
> this function something else? Either way, I'm fine removing the comment
> but I'm genuinely curious.
So this affects for example this hunk:
- if (vr && !range_includes_p (vr, 1))
+ if (vr && (!vr->contains_p (build_one_cst (TREE_TYPE (name)))
+ && !vr->undefined_p ()))
{
I think it's arbitrary how we compute X in UNDEFINED and I'm fine
with changing the affected predicates to return false. This means
not testing for !vr->undefined_p here.
Note I very much dislike the build_one_cst () call here so please
provide an overload hiding this.
Not sure why you keep range_includes_zero_p.
Richard.
>
> OK?
