Re: Problems in IPA passes

[Richard Biener <richard dot guenther at gmail dot com>]

On November 1, 2017 3:12:05 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>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.

I think we can. Maybe add a comment with respect to that to the equiv field. 

>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 :-)

:) 

Thanks for doing this work! (... Strikes one item from too long todo list...) 

Richard. 

>Jeff