Re: ipa vrp implementation in gcc

[Kugan <kugan dot vivekanandarajah at linaro dot org>]

Hi,

> Another potential use of value ranges is the profile estimation. 
> http://www.lighterra.com/papers/valuerangeprop/Patterson1995-ValueRangeProp.pdf
> It seems to me that we may want to have something that can feed sane loop
> bounds for profile estimation as well and we can easily store the known
> value ranges to SSA name annotations.
> So I think separate local pass to compute value ranges (perhaps with less
> accuracy than full blown VRP) is desirable.

Thanks for the reference. I am looking at implementing a local pass for
VRP. The value range computation in tree-vrp is based on the above
reference and uses ASSERT_EXPR insertion (I understand that you posted
the reference above for profile estimation). As Richard mentioned in his
reply, the local pass should not rely on ASSERT_EXPR insertion.
Therefore, do you have any specific algorithm in mind (i.e. Any
published paper or reference from book)?. Of course we can tweak the
algorithm from the reference above but would like to understand what
your intension are.


> I think the ipa-prop.c probably won't need any siginificant changes.  The 
> code basically analyze what values are passed thorugh the function and
> this works for constants as well as for intervals. In fact ipa-cp already
> uses the same ipa-prop analysis for 
>  1) constant propagation
>  2) alignment propagation
>  3) propagation of known polymorphic call contextes.
> 
> So replacing 1) by value range propagation should be easily doable. 
> I would also like to replace alignment propagation by bitwise constant
> propagation (i.e. propagating what bits are known to be zero and what
> bits are known to be one). We already do have bitwise CCP, so we could
> deal with this basically in the same way as we deal with value ranges.
> 
> ipa-prop could use bit of clenaing up and modularizing that I hope will
> be done next stage1 :)

We (Myself and Prathamesh) are interested in working on LTO
improvements. Let us have a look at this.

>>
>>> - Once we have the value ranges for parameter/return values, we could
>>> rely on tree-vrp to use this and do the optimizations
>>
>> Yep.  IPA transform phase should annotate parameter default defs with
>> computed ranges.
> 
> Yep, in addition we will end up with known value ranges stored in aggregates
> for that we need better separate representaiton
> 
> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68930
>>

Thanks,
Kugan