On 6/28/25 2:36 PM, Andrew Pinski wrote:
On Sat, Jun 28, 2025, 1:19 PM Jeff Law <jeffreya...@gmail.com
<mailto: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.
That's great. We should try to make use of it.
The cases where we want to select between 0 and only high bits or 0 and
a bunch of low bits (more than 12 for riscv) is constant synthesis gets
in the way marking the skipped block "not simple". So getting them into
an efficient form, or at least into a conditional move form is going to
be key here.
Jeff
