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
