[RFA][PATCH][tree-optimization/78496] 03/03 Embed and exploit EVRP analysis within DOM

[Jeff Law]

On 12/04/2017 03:42 AM, Richard Biener wrote:
> On Mon, Dec 4, 2017 at 6:59 AM, Jeff Law <law@redhat.com> wrote:
>> And finally, the meat of the fix for pr78496.  This is largely the patch
>> that was posed right when stage1 closed with just minor updates.
>>
>> This patch embeds evrp analysis into DOM and exploits it in the minimal
>> way necessary to fix pr78496 without regressing other tests in the
>> testsuite.
>>
>> The key effect we're looking for here is to pick up a slew of jump
>> threads in DOM2 by exploiting the range information during jump threading.
>>
>> These aren't handled well in the standard tree-vrp jump threading -- we
>> could abuse ASSERT_EXPRs further, but it'd just be ugly and probably
>> computationally expensive.
>>
>> The ranges we want fall out naturally from a dominator walk, hence all
>> the recent work around pulling out EVRP analysis into a little module
>> other passes could reuse.
>>
>> With these changes we pick up all the missing jump thread opportunities
>> in DOM for pr78496.  Sadly, I've been able to pull together an automated
>> test that I like.  About the best I could come up with would be to
>> verify that a large number of jump threads were realized during DOM2.
>> But that still seems rather fragile.  I also looked at examining the
>> results of PRE, but the partial redundancies that were originally the
>> source of complaints in that BZ have already been fixed.  I also looked
>> at perhaps looking for PHIs with constant args and then perhaps trying
>> to filter those, but got nowhere.
>>
>> So there's no direct test for pr78496.  Sigh.
>>
>>
>>
>> Running EVRP analysis in DOM had an unintended side effect.  Namely that
>> SSA_NAMEs that got created after the EVRP optimization pass would have
>> range information attached to them.  That caused two warning regressions
>> with -O1 code in the C++ and Fortran testsuites.  The problem is the
>> ranges attached to the new SSA_NAMES were very wide and there was code
>> left on an unexecutable path that called an allocation routine (C++) and
>> a memset (Fortran) using those names as arguments.  The uber-wide ranges
>> in those circumstances triggered the false positive warnings.
>>
>> By exploiting the EVRP data during the standard part of DOM to optimize
>> conditionals, we're able to prove the paths in question simply aren't
>> executable.  We remove them and the warnings go away.
>>
>> This work compromises builtin-unreachable-6.  So the original test it
>> kept and -fno-tree-dominator-opts is added to keep it from being
>> compromised.  A new builtin-unreachable-6a test is created to very that
>> DOM does indeed remove all the __builtin_unreachable paths.
>>
>> This work also results in us optimizing 20030922-2.c again (conditional
>> equivalences).  EVRP analysis will note the conditional equivalence.  We
>> don't propagate anything from EVRP analysis at this time, but we do use
>> it to try and simplify GIMPLE_CONDs to a compile-time constant which is
>> what happens in this case.
>>
>> I plan to check this in if/when the first two patches are approved.
> 
> Looks good to me.  Btw, did you look at adding a GIMPLE testcase
> for 78496?  You'd have stable IL into DOM then...
I thought about it.  But we're still stuck doing something like counting
jump threads realized.  We have several tests of this nature and they
all feel rather fragile.  So I'm definitely looking for better ways to
handle testing of this stuff.

jeff