On Sat, Jun 28, 2025, 1:19 PM Jeff Law <jeffreya...@gmail.com> wrote:
> > > On 6/27/25 12:20 PM, Andrew Pinski wrote: > > > > > > > > > I have been trying to most of the phiopt to over to use match and > > simplify (via match.pd patterns). Is there an issue why this can't be a > > match pattern instead? It seems like a good fit too. > > It should simplify the code added even. > I can certainly see the appeal in not having to write recognition code > by hand. But I didn't think match.pd handled if-then-else conditionals > sanely. I guess if something is handing us the ternary form reasonably > consistently, then that's a huge step forward. > Yes there is code in phiopt which does this step for you in match_simplify_replacement. It handles up to one statement in each side of the if/then/else to be able to move outside of the conditional. This was done in gcc 12 explicitly to move most of the phiopt over to match. (The min/max has not been fully moved over due to a few match patterns missing dealing with max/min values, it is on my plate still but other things have come up). It also handles reversing the true and false edges with the condition too so you only need one way for the match pattern. And handles early vs non early phiopt too. Thanks, Andrew Pinski > If we set aside the match.pd vs phiopt question the other question in > this space is cost model and canonical form. > > Which of these would be considered the least costly in the gimple model: > > x = c < 0 ? -1 : 16384 > > or > > t = c >> 63; > x = t | 16384; > > or > > if (c < 0) then goto bb1 else goto bb2 > > bb1: > > bb2: > x = phi (-1 (b1), 16384 (bb2)) > > > The first form at least gives targets without a reasonable shifter (h8, > sh, and a few others) a fighting chance to lower to efficient target > code during the gimple->rtl expansion phase. The second option makes it > harder to support the oddballs, but makes the common case easy as we > don't really have to do anything. The last form is undesirable IMHO. > > jeff >
