[range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING

[Aldy Hernandez]

On 7/4/19 6:33 AM, Richard Biener wrote:
> On Wed, Jul 3, 2019 at 2:17 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>>
>> On 7/3/19 7:08 AM, Richard Biener wrote:
>>> On Wed, Jul 3, 2019 at 11:19 AM Aldy Hernandez <aldyh@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.

Aldy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: varying-type.patch
Type: text/x-patch
Size: 35171 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190709/d185d9b2/attachment.bin>