Problems in IPA passes

[Jeff Law]

On 11/01/2017 12:31 AM, Richard Biener wrote:

>> In my local tree I'm just passing around the vrp_bitmap_obstack right
>> now.  Nobody's accessing it via a global anymore.  So at least we know
>> what routines directly or indirectly want to touch vrp_bitmap_obstack.
> 
> Maybe that's not necessary in most places given existing bitmaps know their obstack? IIRC most places do sth to equivalences only if a range already contains some.
I'd think that would help significantly if we're willing to make the 
assumption that all the bitmap allocations come from the same bitmap 
obstack.

For example set_value_range:

  /* Since updating the equivalence set involves deep copying the
      bitmaps, only do it if absolutely necessary.  */
   if (vr->equiv == NULL
       && equiv != NULL)
     vr->equiv = BITMAP_ALLOC (equiv_obstack);

If we assume that the equivalences always allocate from the same 
obstack, we can recover equiv_obstack from equiv->obstack when vr->equiv 
is NULL.

We see a similar pattern in vrp_intersection_ranges_1:

   /* The resulting set of equivalences for range intersection is the 
union of
      the two sets.  */
   if (vr0->equiv && vr1->equiv && vr0->equiv != vr1->equiv)
     bitmap_ior_into (vr0->equiv, vr1->equiv);
   else if (vr1->equiv && !vr0->equiv)
     {
       vr0->equiv = BITMAP_ALLOC (equiv_obstack);
       bitmap_copy (vr0->equiv, vr1->equiv);
     }

We can use vr1->equiv->obstack to get to the obstack when vr0->equiv is 
NULL.

But the first, in set_value_range is probably the most important.

This may also enable certain functions to remain as free functions 
rather than having to move into a class.  They should be easy to spot as 
well.

Again, the positive is this can be tested very quickly now.  The joys of 
losing the global and getting some refactoring in done :-)

Jeff