On Wed, Apr 26, 2023 at 4:30 AM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 4/25/23 01:21, Richard Biener wrote: > > On Tue, Apr 25, 2023 at 1:05 AM Jeff Law <jeffreya...@gmail.com> wrote > >> > >> > >> > >> > >> On 4/24/23 02:06, Richard Biener via Gcc-patches wrote: > >>> On Fri, Apr 21, 2023 at 11:01 PM Philipp Tomsich > >>> <philipp.toms...@vrull.eu> wrote: > >>>> > >>>> Any guidance on the next steps for this patch? > >>> > >>> I think we want to perform this transform later, in particular when > >>> the test is a loop exit test we do not want to do it as it prevents > >>> coalescing of the IV on the backedge at out-of-SSA time. > >>> > >>> That means doing the transform in folding and/or before inlining > >>> (the test could become a loop exit test) would be a no-go. In fact > >>> for SSA coalescing we'd want the reverse transform in some cases, see > >>> PRs 86270 and 70359. > >>> > >>> If we can reliably undo for the loop case I suppose we can do the > >>> canonicalization to compare against zero. In any case please split > >>> up the patch (note > >> I've also > >>> hoped we could eventually get rid of that part of > >>> tree-ssa-forwprop.cc > >> in favor > >>> of match.pd patterns since it uses GENERIC folding :/). > >>> > >> Do we have enough information to do this at expansion time? That would > >> avoid introducing the target dependencies to drive this in gimple. > > > > I think so, but there isn't any convenient place to do this I think. I > > suppose > > there's no hope to catch it during RTL opts? > Combine would be the most natural place in the RTL pipeline, but it'd be > a 2->2 combination which would be rejected. > > We could possibly do it as a define_insn_and_split, but the gimple->RTL > interface seems like a better fit to me. If TER has done its job, we > should see a complex enough tree node to do the right thing.
Of course we'd want to get rid of TER in favor of ISEL Richard. > jeff
