[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons

["wschmidt at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848

--- Comment #15 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #14)
> On November 5, 2016 4:31:54 PM GMT+01:00, "wschmidt at gcc dot gnu.org"
> <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> >Notable degradations:
> >  403.gcc:         -1.8%
> >
> >Other results in noise (+/- 1.0%)
> >
> >Thus, not too bad for a simple patch, though we don't like seeing
> >403.gcc
> >degrade.
> 
> Analyzing would be useful, I suspect missed RTL if-conversion opportunities.

Agreed; however, I may not be able to get to that this week, unfortunately.

> 
> >I've made some progress on the outer loop vectorization issue, but
> >haven't
> >completely solved it yet.  I'll try to have something to look at there
> >in the
> >next couple of days.
> 
> I'd try detecting the outer loop vect CFG shape the vectorizer handles in
> if-combersion and then simply version the outer loop...  Of course needs
> handling of the VECTORIZED conditional on an outer loop in the vectorizer.

Right, that's the direction I've been exploring.  Unfortunately the loop
analysis seems pretty dependent on the shape, and things get ugly inside
vect_mark_stmts_to_be_vectorized.  Eventually I run into the following that
defeats outer loop vectorization:

/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: def_stmt: curr_a_20 = PHI <curr_a_11(7), curr_a_26(11)>
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: type of def: unknown
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: Unsupported pattern.
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: not vectorized: unsupported use in stmt.
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-cond-1.c:2\
0:3: note: unexpected pattern.

Here the PHI in question is in the loop header for the inner unoptimized loop,
which is unexpected by the analysis and becomes vect_unknown_def_type.  Thus we
hit the "Unsupported pattern" in vect_is_simple_use and we're done.

I tried an egregious hack to just ignore such PHIs in nested loops to see what
would happen.  We end up blowing up deep in the analyze_overlapping_iterations
code during data-ref analysis.

I'm somewhat at a dead end here, so I'll attach the patch thus far and call it
a night.  I'd appreciate any thoughts on any better direction.  The hunk in
vect_is_simple_use is the egregious hack; it needs to be removed before the
test case will compile.