Re: ipa vrp implementation in gcc

[vivek pandya <vivekvpandya at gmail dot com>]

> On Mon, Jan 11, 2016 at 4:07 PM, Richard Biener <richard.guenther@gmail.com>
> wrote:
>>
>> On Mon, Jan 11, 2016 at 1:38 AM, Kugan
>> <kugan.vivekanandarajah@linaro.org> wrote:
>> > Hi All,
>> >
>> > I am looking at implementing a ipa vrp pass. Jan Hubicka also talks
>> > about this in 2013 GNU Cauldron as one of the optimization he would like
>> > to see in gcc. So my question is, is any one implementing it. If not we
>> > would like to do that.
>> >
>
> Hello I am Vivek Pandya, I am actually working on a GSoC 2016 proposal for
> his work and it is very similar to extending ipa-cp pass. I am also in touch
> with Jan Hubicka. These comments will certainly help me but if is urgent for
> any one you can begin work on this. Jan has shown interest to mentor me for
> this project but any help from community is always appreciated.
>
>>
>> > I also looked at the ipa-cp implementation to see how this can be done.
>> > Going by this, one of the way to implement this is (skipping all the
>> > details):
>> >
>> > - Have an early tree-vrp so that we can have value ranges for parameters
>> > at call sites.
>
> Actually a tree-vrp pass already exists. But as Jan has suggested me that
> ipa-vrp implementation should not be too much costly. So I am also thinking
> to include this work in my proposal and also using the analysis to improve
> LTO heuristics as the project duration will be around 2.5 months.
>>
>>
>> I'd rather use the IPA analysis phase for this and use a VRP algorithm
>> that doesn't require ASSERT_EXPR insertion.
>>
>> > - Create jump functions that captures the value ranges of call sites
>> > propagate the value ranges. In 2013 talk, Jan Hubicka talks about
>> >
>> > - Modifying ipa-prop.[h|c] to handles this but wouldn't it be easier to
>> > have its own and much more simpler implementation ?
>>
>> No idea.
>>
>> > - 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.
>>
>> > Does this make any sense? Any thoughts/suggestions to work on this is
>> > highly appreciated.
>>
>> IPA alignment propagation should already be somewhat similar as in doing
>> an intersection step during propagation.
>>
>> Richard.
>>
>> > Thanks,
>> > Kugan
>
> Your comments certainly helps me to develop my proposal. Please let me know
> any updated to avoid the confusion and duplication of work.
> Sincerely,
> Vivek