On Fri, Jul 21, 2017 at 9:30 PM, Aldy Hernandez <al...@redhat.com> wrote: > On Mon, Jul 17, 2017 at 6:23 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Mon, Jul 17, 2017 at 8:51 AM, Aldy Hernandez <al...@redhat.com> wrote: > >>> How does this look? >> >> It's a change that on its own doesn't look worthwhile to me. >> >> So please post the changes that will build ontop of this. Like removing >> anti-ranges from VRP or your on-demand value-range stuff. >> >> Thanks, >> Richard. > > From the looks of it, we can have a variety of VRP ranges that are not > representable at all with the an integer range class. For instance, I > see the following ranges built in set_value_range(): > > [INT, (nop_expr SSA)] > > [INT, (plus_expr SSA INT)] > > [(negate_expr SSA), (negate_expr SSA)] > > [(plus_expr (negate_expr SSA INT)), > (plus_expr (negate_expr SSA) INT)] > > [SSA, SSA] > > So...I guess the first suggestion is out of the question ;-).
Well. We do not want range operations implemented twice (really!) so range operations need to work on both representations. So we should think of a way to get rid of anti-ranges in VRP which, frankly, means that for the sake symbolic ranges we have to trade them with handling open/closed ranges which I'm not sure will be less of a hassle to handle? Richard. > Aldy
