This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ipa vrp implementation in gcc

On Mon, Jan 18, 2016 at 12:00 AM, Kugan
<> wrote:
> Hi,
>> 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
> Thanks,
> Kugan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]