On Mon, May 4, 2015 at 3:57 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Mon, 4 May 2015, Richard Biener wrote: > >> On Sat, May 2, 2015 at 12:46 AM, Marc Glisse <marc.gli...@inria.fr> wrote: >>> >>> Hello, >>> >>> this patch tries to tighten a bit the range estimate for x%y. >>> slp-perm-7.c >>> started failing by vectorizing more than expected, I assumed it was a >>> good >>> thing and updated the test. I am less conservative than Jakub with >>> division >>> by 0, but I still don't really understand how empty ranges are supposed >>> to >>> be represented in VRP. >>> >>> Bootstrap+testsuite on x86_64-linux-gnu. >> >> >> Hmm, so I don't like how you (continute to) use trees for the constant >> computations. wide-ints would be a better fit today. I also notice that >> fold_unary_to_constant can return NULL_TREE and neither the old nor your >> code handles that. > > > You are right. I was lazy and tried to keep this part of the old code, I > shouldn't have... > >> "empty" ranges are basically UNDEFINED. > > > Cool, that's what I did. But I don't see code adding calls to > __builtin_unreachable() when an empty range is detected. Maybe that almost > never happens?
No, it's just nobody bothered to implement it. You also have to be careful as you can't replace reproducers of UNDEFINED but only uses that still result in UNDEFINED result (for example 0 * UNDEFINED is defined again). What I'd like to do at some point is have some common code that you can query what OP1 tree_code OP2 evaluates to if either op is UNDEFINED. For example UNDEF + X == UNDEF but UNDEF * X == 0 (as optimistical result, of course - the only not undefined case is for X == 0). UNDEF << X == 0 but UNDEF >> X == signed(x) ? UNDEF : 0. We have multiple passes that duplicate only parts of those "optimizations". Having a central place implementing this correctly would be nice. >> Aren't you pessimizing the case where the old code used >> value_range_nonnegative_p() by just using TYPE_UNSIGNED? > > > I don't think so. The old code only handled signed types in the positive > case, while I have a more complete handling of signed types, which should do > at least as good as the old one even in the positive case. Ok, I see. Richard. > -- > Marc Glisse
