On 5/2/19 7:23 AM, Richard Biener wrote: > On Thu, May 2, 2019 at 3:17 PM Jeff Law <l...@redhat.com> wrote: >> >> On 5/2/19 6:22 AM, Richard Biener wrote: >>> On Wed, May 1, 2019 at 7:32 PM Jeff Law <l...@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... :/ Actually we do have cases in the testsuite which show examples of where we do want it (from coremark IIRC).
I don't think we've done much in here over the last couple years. I think all I've done is add the half-diamond ifcvt check and the ternary stuff this week. If I was to pick one thing to do it would be to reorganize the ifcvt code a so that we could query it and use the results of that query to throttle back path splitting. What we're doing in the path splitting code to detect ifcvt opportunities is lame/bandaids. But I think we have bigger issues on our plate than this stuff :-) > >> 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 ;) Of course. Note that the ability to query and filter out ifcvt opportunities would cut down on the potential explosion here too. > > 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. Yea. Or some kind of explore code generation approaches and prune. But that feels all pie in the sky to me. Jeff
