On November 1, 2017 3:12:05 PM GMT+01:00, Jeff Law <[email protected]> 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
