This is the mail archive of the
mailing list for the GCC project.
Re: ipa vrp implementation in gcc
- From: vivek pandya <vivekvpandya at gmail dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 11 Jan 2016 22:59:13 +0530
- Subject: Re: ipa vrp implementation in gcc
- Authentication-results: sourceware.org; auth=none
- References: <5692F974 dot 2000805 at linaro dot org> <CAFiYyc0jJpQmg4uh8EhAC0S84=JyBqWdz3rRYuwi85M9YTzecA at mail dot gmail dot com> <CAHYgpoKLrWmDV1d1_K_1naQZhGxehAifvq3esnA1D27a0T0QBA at mail dot gmail dot com>
> On Mon, Jan 11, 2016 at 4:07 PM, Richard Biener <firstname.lastname@example.org>
>> On Mon, Jan 11, 2016 at 1:38 AM, Kugan
>> <email@example.com> 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.
>> > 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.