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.
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
