This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Adjusted VRP
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Marat Zakirov <m dot zakirov at samsung dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Yury Gribov <y dot gribov at samsung dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Maksim Ostapenko <m dot ostapenko at partner dot samsung dot com>
- Date: Thu, 30 Oct 2014 14:28:07 +0100
- Subject: Re: [RFC] Adjusted VRP
- Authentication-results: sourceware.org; auth=none
- References: <5451093F dot 2090905 at samsung dot com> <CAFiYyc1p71zTqrr0kxyadGJVxqVby6A+SA6=PeVRkGVM-qsBaQ at mail dot gmail dot com> <54521DF4 dot 50508 at samsung dot com> <20141030113250 dot GD10376 at tucnak dot redhat dot com> <54523ADC dot 7090704 at samsung dot com>
On Thu, Oct 30, 2014 at 2:19 PM, Marat Zakirov <m.zakirov@samsung.com> wrote:
> On 10/30/2014 02:32 PM, Jakub Jelinek wrote:
>>
>> On Thu, Oct 30, 2014 at 02:16:04PM +0300, Yury Gribov wrote:
>>>
>>> On 10/30/2014 01:27 PM, Richard Biener wrote:
>>>>
>>>> Well, VRP is not path-insensitive - it is the value-ranges we are able
>>>> to retain after removing the ASSERT_EXPRs VRP inserts.
>>>>
>>>> Why can't you do the ASAN optimizations in the VRP transform phase?
>>>
>>> I think this is not Asan-specific: Marat's point was that allowing
>>> basic-block-precise ranges would generally allow middle-end to produce
>>> better code.
>>
>> The reason for get_range_info in the current form is that it is cheap, and
>> unless we want to make some SSA_NAMEs non-propagatable [*], IMHO it should
>> stay that way. Now that we have ASAN_ internal calls, if you want to
>> optimize away ASAN_CHECK calls where VRP suggests that e.g. array
>> index will be within the right bounds and you'd optimize away ASAN_CHECK
>> to
>> a VAR_DECL access if the index was constant (say minimum or maximum of the
>> range), you can do so in VRP and it is the right thing to do it there.
>>
>> [*] - that is something I've been talking about for __builtin_unreachable
>> ()
>> etc., whether it would be worth it if range_info of certain SSA_NAME that
>> would VRP want to remove again was significantly better than range info of
>> the base SSA_NAME, to keep that SSA_NAME around and e.g. block forwprop
>> etc.
>> from propagating the SSA_NAME copy, unless something other than SSA_NAME
>> has
>> been propagated into it. Richard was against that though.
>>
>> Jakub
>>
>
> We didn't find reasonable performance gains to use VRP in asan. But even if
> we found we couldn't use it because it is not safe for asan. It make some
> optimistic conclusions invalid for asan.
>
> Adjusted VRP memory upper bound is #{trees that are compared} x nblocks
> which could be reduced by some threshold.
>
> If making stuff inside VRP is a right thing why can't we do all
> VRP-dependent optimizations in the VRP transform phase?
Because for example you can't do RTL expansion from VRP ;)
> Why do we need
> range_infos if they are so imprecise?!
Because even imprecise range-info is better than no range-info.
Richard.
>