On Mon, Jan 18, 2016 at 12:00 AM, Kugan <kugan.vivekanandara...@linaro.org> 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). Richard. >> 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
