This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Adjusted VRP
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marat Zakirov <m dot zakirov at samsung dot com>
- Cc: Yury Gribov <y dot gribov at samsung dot com>, Richard Biener <richard dot guenther at gmail 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:31:38 +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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Oct 30, 2014 at 04:19:24PM +0300, Marat Zakirov wrote:
> 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? Why do we need
> range_infos if they are so imprecise?!
It is not imprecise, and really isn't (so far) used that heavily in the
compiler, most of the optimizations based on value ranges really do happen
in the VRP tansform phase.
Jakub