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>, mjambor at suse dot cz
- Date: Mon, 11 Jan 2016 18:51:52 +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>
> On Mon, Jan 11, 2016 at 1:38 AM, Kugan
> <firstname.lastname@example.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.
> > 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.
> I'd rather use the IPA analysis phase for this and use a VRP algorithm
> that doesn't require ASSERT_EXPR insertion.
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.
> > - 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.
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 :)
> > - 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
> > 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.
The merge operation is same as VRP does, but yep, IPA alignment code is good
one to follow for start. Martin implemented it in a bit limited way so it
never performs cloning, but we can deal with that incrementally.
> > Thanks,
> > Kugan