On Tue, Aug 4, 2020 at 8:39 AM Aldy Hernandez via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > It seems to me that we should also check for [0,0] and [1,1] in the > range, but I am leaving things as is to avoid functional changes. > > gcc/ChangeLog: > > * vr-values.c (simplify_using_ranges::op_with_boolean_value_range_p): > Adjust > for irange API. > --- > gcc/vr-values.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/gcc/vr-values.c b/gcc/vr-values.c > index 609375c072e..1190fa96453 100644 > --- a/gcc/vr-values.c > +++ b/gcc/vr-values.c > @@ -448,10 +448,11 @@ simplify_using_ranges::op_with_boolean_value_range_p > (tree op) > if (TREE_CODE (op) != SSA_NAME) > return false; > > + /* ?? Errr, this should probably check for [0,0] and [1,1] as well > + as [0,1]. */ > const value_range *vr = get_value_range (op); > - return (vr->kind () == VR_RANGE > - && integer_zerop (vr->min ()) > - && integer_onep (vr->max ())); > + return *vr == value_range (build_zero_cst (TREE_TYPE (op)), > + build_one_cst (TREE_TYPE (op)));
This now builds trees in a predicate which is highly dubious. Isn't there a better (cheaper) primitive to build a [0, 1] range to compare against? I guess from what I read it will also allocate memory for the range entry? Richard. > } > > /* Extract value range information for VAR when (OP COND_CODE LIMIT) is > -- > 2.26.2 >
