This is the mail archive of the
mailing list for the GCC project.
Re: ipa vrp implementation in gcc
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Kugan <kugan dot vivekanandarajah at linaro dot org>, 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 18:10:44 +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> <CAFiYyc2gOWZixd=MwsvReg2vfeu2m87mEQ3U04OEMhAEb7VeuQ at mail dot gmail dot com>
> On Mon, Jan 18, 2016 at 12:00 AM, Kugan
> <email@example.com> wrote:
> > 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 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).
In general, given that we have existing VRP implementation I would suggest
first implementing the IPA propagation and profile estimation bits using
existing VRP pass and then try to compare the simple dominator based approach
with the VRP we have and see what are the compile time/code quality effects
of both. Based on that we can decide how complex VRP we really want.
It will be probably also more fun to implement it this way :)
I plan to collect some data on early VRP and firefox today or tomorrow.
> >> 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