Re: [PATCH 2/n] [PR tree-optimization/78496] Simplify ASSERT_EXPRs to facilitate jump threading

[Jeff Law <law at redhat dot com>]

On 05/08/2017 01:25 AM, Richard Biener via gcc-patches wrote:
> > ps. An astute observer might note that improving the effectiveness of VRP
> > jump threading seems counterproductive since I've stated I want to remove
> > VRP jump threading.  These improvements don't significantly change how I was
> > planning to do that or the infrastructure we're going to rely upon to make
> > that change.  All that changes is where we get the information from --
> > ASSERT_EXPRs vs querying a new API that generates the same information as
> > needed.
>
> That API is already there.  It's called register_edge_assert_for (it might need
> a wrapper to be most useful and also needs to be exported / moved from VRP
> to somewhere else).  Both VRP and EVRP use it to "compute" ASSERT_EXPRs
As I mentioned in an earlier message, this has a lot of similarity with 
what Andrew has been doing.  Furthermore, parts of this mimick code I've 
written in DOM and code we need for the backward threader to make it 
strong enough to eliminate the VRP threading code.  I'd really like to 
be working on unifying all that work within the next few days (as 
originally hoping for today, but slightly side-tracked last week).



> So I'm not sure if changing VRP with your patches is a good thing when you
> could have used the new API in the first place ...
I don't see that the changes to date around 78496 change things 
significantly in regards to the immediate plans to remove ASSERT_EXPR. 
The work around 78496 raises the bar in terms of what information we 
need to be able to extract, but that IMHO, is a fine thing to do ;-)


However, the existence of register_edge_assert_for does change how I'm 
looking at the next issue for 78496 as well as how to tackle a host of 
related issues.  It may end up being the case that we stop 78496 work 
after patch #2, work on ASSERT_EXPR removal, then re-eval 78496.

Jeff