Re: [committed] [PR tree-optimization/88797] Thottle back path splitting in another case where it'll inhibit if-conversion

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, May 2, 2019 at 3:17 PM Jeff Law <law@redhat.com> wrote:
>
> On 5/2/19 6:22 AM, Richard Biener wrote:
> > On Wed, May 1, 2019 at 7:32 PM Jeff Law <law@redhat.com> wrote:
> >>
> >>
> >> This fixes pr88797 by avoiding path splitting when we've got a
> >> candidate, but the PHI feeds a conditional in the join block.  ie:
> >>
> >>   # iftmp.0_11 = PHI <1111(3), 1112(4)>
> >> [ ... ]
> >>   _14 = iftmp.0_11 > x_17;
> >>
> >>
> >> These are more likely going to be if-conversion candidates and
> >> if-conversion is generally more profitable than path splitting.
> >>
> >> This doesn't feel terribly important to fix for gcc-9, so I'm just
> >> installing on the trunk.  But backporting would be trivial and safe if
> >> someone feels it's important enough to do so.
> >>
> >> This has been bootstrapped and regression tested on a variety of native
> >> targets, it's also been tested to a lesser degree on the various *-elf
> >> targets.
> >>
> >> Installing on the trunk momentarily.
> >
> > IMHO we should get rid of path splitting and try to integrate its transform
> > with (backward) threading somehow.
> BUt that wouldn't change the fundamental problem that we don't have a
> good way to model costs/benefits.

True.  But here we seem to be adding more and more cases where we do
_not_ want the transform to a pass initially having not a single case
where we _do_ want it... :/

> What would be slick would be to create two loops, then do a final
> selection on which to keep after if-conversion or something along those
> lines.

Of course this scheme quickly explodes it you apply it to more than one
transform ;)

For optimizations like loop unrolling or jump threading I've always
wanted to use the
--params we have to limit growth and simply do "code generation" of the paths
with doing VN on the fly, simply stopping after those N instructions.
That would
make it constant time but allow possibly large paths to be handled if
they simplify
significantly.  The main issue is context for the VN process for the
path entry which
is of course either not present (cheap) or expensive to compute.

Richard.

> jeff