On October 31, 2017 4:47:06 AM GMT+01:00, Jeff Law <l...@redhat.com> wrote:
>On 10/29/2017 03:54 PM, Kugan Vivekanandarajah wrote:
>> Hi Jeff,
>>
>> On 28 October 2017 at 18:28, Jeff Law <l...@redhat.com> 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 :(
Equivalence shouldn't be used from the extract_range_from_* routines. Vrp_meet
probably uses them though. Factoring this function would be nice.
Richard.
