On 10/30/2014 04:19 PM, Marat Zakirov 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.
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.
Do you have some concrete numbers at hand?
-Y
