Re: Problems in IPA passes
On 10/28/2017 11:18 AM, Richard Biener wrote: > On October 28, 2017 9:28:38 AM GMT+02:00, Jeff Law wrote: >> >> Jan, >> >> What's the purpose behind calling vrp_meet and >> extract_range_from_unary_expr from within the IPA passes? >> >> AFAICT that is not safe to do. Various paths through those routines >> will access static objects within tree-vrp.c which may not be >> initialized when IPA runs (vrp_equiv_obstack, vr_value). >> >> While this seems to be working today, it's a failure waiting to happen. > > Those functions are fine to use IIRC. You have to look at how they interact with those global variables within tree-vrp.c They're complex enough that I can't convince myself they're actually safe. And even if they're safe today, the lack of encapsulation makes them ripe to be broken later by accident. Jeff
Re: Problems in IPA passes
On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
>
> On 28 October 2017 at 18:28, Jeff Law wrote:
>>
>> Jan,
>>
>> What's the purpose behind calling vrp_meet and
>> extract_range_from_unary_expr from within the IPA passes?
>
> This is used such that when we have an argument to a function and this
> for which we know the VR and this intern is passed as a parameter to
> another. For example:
>
> void foo (int i)
> {
> ...
> bar (unary_op (i))
> ...
> }
>
> This is mainly to share what is done in tree-vrp.
Presumably you never have equivalences or anything like that, which
probably helps with not touching vrp_bitmap_obstack which isn't
initialized when you run the IPA bits.
>>
>> AFAICT that is not safe to do. Various paths through those routines
>> will access static objects within tree-vrp.c which may not be
>> initialized when IPA runs (vrp_equiv_obstack, vr_value).
>
> IPA-VRP does not track equivalence and vr_value is not used.
But there's no enforcement and I'd be hard pressed to believe that all
the paths through the routines you use in tree-vrp aren't going to touch
vr_value, or vrp_bitmap_obstack. vrp_bitmap_obstack turns out to be
incredibly tangled into the implementations within tree-vrp.c :(
