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? Why do we need
range_infos if they are so imprecise?!
