This is the mail archive of the
mailing list for the GCC project.
Re: ipa vrp implementation in gcc
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Kugan <kugan dot vivekanandarajah at linaro dot org>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>, Prathamesh Kulkarni <prathamesh dot kulkarni at linaro dot org>
- Date: Mon, 18 Jan 2016 10:42:43 +0100
- 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> <20160111175152 dot GA24114 at kam dot mff dot cuni dot cz> <569C1D21 dot 5010803 at linaro dot org>
On Mon, Jan 18, 2016 at 12:00 AM, Kugan
>> Another potential use of value ranges is the profile estimation.
>> 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 have (very incomplete) prototype patches to do a dominator-based
approach instead (what is refered to downthread as non-iterating approach).
That's cheaper and is what I'd like to provide as an "utility style" interface
to things liker niter analysis which need range-info based on a specific
dominator (the loop header for example).
>> 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