On 7/9/19 5:56 AM, Richard Biener wrote:
On Tue, Jul 9, 2019 at 9:28 AM Aldy Hernandez <al...@redhat.com> wrote:
On 7/4/19 6:33 AM, Richard Biener wrote:
On Wed, Jul 3, 2019 at 2:17 PM Aldy Hernandez <al...@redhat.com> wrote:
On 7/3/19 7:08 AM, Richard Biener wrote:
On Wed, Jul 3, 2019 at 11:19 AM Aldy Hernandez <al...@redhat.com> wrote:
How about we keep VARYING and UNDEFINED typeless until right before we
call into the ranger. At which point, we have can populate min/max
because we have the tree_code and the type handy. So right before we
call into the ranger do:
if (varying_p ())
foo->set_varying(TYPE);
This would avoid the type cache, and keep the ranger happy.
you cannot do set_varying on the static const range but instead you'd do
value_range tem (*foo);
if (varying_p ())
tem->set_full_range (TYPE);
which I think we already do in some places. Thus my question _where_
you actually need this.
Basically, everywhere. By having a type for varying/undefined, we don't
have to special case anything. Sure, we could for example, special case
the invert operation for undefined / varying. And we could special case
everything dealing with ranges to handle varying and undefined, but why?
We could also pass a type argument everywhere, but that's just ugly.
However, I do understand your objection to the type cache.
How about the attached approach? Set the type for varying/undefined
when we know it, while avoiding touching the CONST varying. Then right
before calling the ranger, pass down a new varying node with min/max for
any varyings that were still typeless until that point.
I have taken care of never adding a set_varying() that was not already
there. Would this keep the const happy?
Technically we don't need to set varying/undef types for every instance
in VRP, but we need it at least for the code that will be shared with
range-ops (extract_range_from_multiplicative_op, union, intersect, etc).
I just figured if we have the information, might as well set it for
consistency.
If you like this approach, I can rebase the other patches that depend on
this one.
OK, so I went ant checked what you do for class irange which has
a type but no kind member (but constructors with a kind). It also
uses wide_int members for storage. For a pure integer constant
range representation this represents somewhat odd choices; I'd
have elided the m_type member completely here, it seems fully
redundant. Only range operations need to be carried out in a
specific type (what I was suggesting above). Even the precision
encoded in the wide_int members is redundant then (I'd have
expected widest_int here and trailing-wide-ints for optimizing
storage).
What irange contains internally is a bit arbitrary. It's really an API
for managing a set of subranges. We could have used trees internally
just as easily, then we wouldnt need a type field. Since we were doing
lots of operations, rather than going back and forth from trees all the
time, we just used the underlying wide_int directly. we could have
fiddle farted around with HOST_WIDE_INT or whatever, but wide_int is
there, has all the operations, and it works fine. so thats what it
currently is on the branch.
We are treating a range object as a unique self contained object.
Therefore, the range has a type so we know how to print it, and can
confirm before any operation that the ranges being operated on are
appropriately matched. We found and opened bugzillas over the past
couple years for places where our code caught bugs because a range was
created and then operated on in a way that was not compatible with
another range. I think there is a still an open one against ada(?)
where the switch and case are different precision.
From my point of view, a range object is similar to a tree node. A tree
node has the bits to indicate what the value is, but also associates a
type with those bits within the same object. This is less error prone
than passing around the bits and the type separately. As ranges are
starting to be used in many places outside of VRP, we should do the same
thing with ranges. WIth value_range it would actually be free since
there is already a tree for the bounds already which contains the type.
to fold_range/op_range? The API also seems to be oddly
constrained to binary ops. Anyway, the way you build
the operator table requires an awful lot of global C++ ctor
invocations, sth we generally try to avoid. But I'm getting
into too many details here.
Its "oddly constrained" because what you are looking at is just the
standardized unary/binary ops code.. ie the equivalent of
extract_range_from_binary_expr() and extract_range_from_unary_expr().
The other ops we care about have specialized requirements, like PHIs
and the arbitrary numbers of parameters in a call, or anything less
common than one or two operands. You are just not seeing those parts.
So - to answer your question above, I'd like you to pass down
a type to operations. Because that's what is fundamentally
required - a range doesn't have a "type" and the current
value_range_base doesn't fall into the trap of needing one.
Richard.
Why is having a type associated with the data a "trap"? Perhaps the
old VRP lattice idea didn't need a type with the UNDEFINED and VARYING
lattice values, but we're moving past lattice values and into a realm
where we have ranges as useful things outside of VRP, and trying to
shoehorn lattice values does not seem appropriate anymore.
I looked at implementing range-ops without a type in the range, and we
end up passing 2 parameters everywhere each time we do anything with a
range. This doubled the number of parameters in most routines, and when
we had chains of calls, we were simply passing the type along with the
range. It seems archaic to be constantly passing information around
instead of associating it with the range itself. Its just another place
for an error to creep in.. Aldy found a place where we were creating
varying nodes for floats IIRC.. the type checking in the range
operations caught it precisely because the range returned wasn't the
type it was assumed to be.
That said. I believe we can do away with the need for a type with an
'UNDEFINED' range. That is not too onerous, and there doesn't really
seem to be too many ripple effect from have a typeless undefined range.
I think we can contain that, and prevents us from having to add a hack
to value_range for that situation.
VARYING is another situation completely. We adopted the term 'varying'
for ease of compatibility with VRP, but varying is simply a range going
from MIN to MAX for a type. Removing the type from that would then
require we always pass a type in with every range which gets back to
doubling the number of of parameters everywhere for no good reason.
If we standardize value_range so that MIN and MAX are set for varying,
then everything works very smoothly, we can make value_range and irange
interchangeable and facilitate getting the range ops code into trunk.
It seems like the only reason we cant do this right now is the CONST
varying nodes that are returned from get_value_range().
Looking at that routine, it seems there are only 2 cases where that can
be returned
1) we ask for an ssa-name beyond the end of the local ssa-name vector
2) once values_propagated is set to true and an ssa-name has no entry.
Both seem pretty straightforward to fix...
1) if we ask for an ssa-Name beyond the end, simply reallocate the
vector to be big enough. I doubt this will trigger a lot, and if we
initially allocate it with room for an extra 10% names it'll probably
never trigger. Or pick whatever number seems appropriate.
2) if values_propagated is true, simply allocate a node for the
ssa-name, set it to varying and return it. THIs accomplishes the same
thing.
the number of additional nodes we allocate will be pretty minimal, and
it will never exceed the number of ssa-names. Then we never have to
worry about having CONST set for a varying node either. I see places
where there is special processing to avoid calling set_varying because
we dont know if the vbalue_range in hand is in constant memory and would
cause the compiler to trap. This seems like a really bad situation, and
it would eliminate that issue. We can also then eliminate the places
where VARYING is expanded to min/max for a given type.. instead we can
just pick up min/max directly. It seems much cleaner overall.
Something like the simple attached patch would resolve that issue, and
remove any lurking concerns/bugs with the CONST code.
Then we can associate a type with varying, canonicalize it consistently,
and set MIN/MAX appropriately. This will give us full
interchangeability between irange and value_range, establish a
solid/consistent API, and we can move on to the next thing :-)
Does this not seem reasonable?
Andrew
Index: vr-values.c
===================================================================
--- vr-values.c (revision 272242)
+++ vr-values.c (working copy)
@@ -91,18 +91,28 @@
We should get here at most from the substitute-and-fold stage which
will never try to change values. */
if (ver >= num_vr_values)
- return CONST_CAST (value_range *, &vr_const_varying);
+ {
+ unsigned int old_sz = num_vr_values;
+ num_vr_values = num_ssa_names + num_ssa_names / 10;
+ vr_value = XRESIZEVEC (value_range *, vr_value, num_vr_values);
+ for ( ; old_sz < num_vr_values; old_sz++)
+ vr_value [old_sz] = NULL;
+ }
vr = vr_value[ver];
if (vr)
return vr;
- /* After propagation finished do not allocate new value-ranges. */
+ /* Create a default value range. */
+ vr_value[ver] = vr = vrp_value_range_pool.allocate ();
+
+ /* After propagation finished return varying. */
if (values_propagated)
- return CONST_CAST (value_range *, &vr_const_varying);
+ {
+ vr->set_varying ();
+ return vr;
+ }
- /* Create a default value range. */
- vr_value[ver] = vr = vrp_value_range_pool.allocate ();
vr->set_undefined ();
/* If VAR is a default definition of a parameter, the variable can
@@ -1920,7 +1930,7 @@
vr_values::vr_values () : vrp_value_range_pool ("Tree VRP value ranges")
{
values_propagated = false;
- num_vr_values = num_ssa_names;
+ num_vr_values = num_ssa_names + num_ssa_names / 10;
vr_value = XCNEWVEC (value_range *, num_vr_values);
vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names);
bitmap_obstack_initialize (&vrp_equiv_obstack);