On 02/08/2017 05:53 AM, Richard Biener wrote:
Bah.
Add a nonnull_p flag to value_range ...
/me runs...
Honestly, the way to go is ditch VR_ANTI_RANGE and make value_range be
// template <unsigned N>
struct GTY(()) value_range
{
enum value_range_type type;
// The value range is the union of [ min[0], max[0] ], [ min[1], max[1] ] ...
tree min[N];
tree max[N];
bitmap equiv;
};
or better use a sub-struct for the individual sub-ranges (and maybe a vec so
that the actual N is variable and we just impose an upper limit somewhere).
Agreed. Seems like a gcc-8 thing though.
for the moment with fixed N == 2. Then we can represent [MIN/4, 1] U [MAX/4, 1]
exactly.
And probably other important cases as well. But I suspect there's
little to be gained beyond N == 2.
Btw, there's always much talk about that mysterious VRP improvements by Andrew.
I hope he doesn't mind if his work gets torn apart during hypothetical
review which
usually happens if you develop stuff somewhere hidden in a dark
corner... and yes,
I didn't want to duplicate any work and thus I refrained from doing
the above kind of
refactorings at the end of stage1.
Yea. I've been trying to steer him away from that methodology :-) He
won't mind the work being torn apart. We'll actually be talking about
its state next week..
I think his work is largely outside VRP right now, so if you want to go
forward with refactorings, I'd say go for it without worrying abou
tAndrew's work. Odds are there won't be a lot of overlap. I'm happy to
drag Andrew onto a call where the three of us can your refactoring plans
and Andrew's plans around to see where there's overlap.
jeff
