On 6/30/25 2:18 AM, Richard Biener wrote:
On Sat, 28 Jun 2025, Jeff Law 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.
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
cost 1
or
t = c >> 63;
x = t | 16384;
cost 2
or
if (c < 0) then goto bb1 else goto bb2
bb1:
bb2:
x = phi (-1 (b1), 16384 (bb2))
cost 2
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.
IMO we need to select a "canonical" variant that is easy to transform
into one of the others which rules out the >>| form.
That works for me.
So I think the overall direction is:
1. Try to do the translation in match.pd
2. Target the conditional move form
3. Adjust expanders and/or target bits as necessary to avoid regressions
Right?
Jeff
