On 12/1/25 4:32 AM, Dongyan Chen wrote:
Thanks for the guidance. I have filed the bug : https://gcc.gnu.org/
bugzilla/show_bug.cgi?id=122935
TYVM.
I noticed that GCC on x86-64 also misses this optimization, which
suggests this maybe generally beneficial for targets with expensive
multiplication. Given this, would you advise investigating a generic RTL
fix (e.g., in simplify-rtx.cc)?
We could try to make a case that the multiply, even though its a single
op is an exception to the simplistic cost model of gimple. I'm not sure
that's a great solution, but it's worth keeping in mind.
You could try to see if it could be improved at expansion time, we
should be able to see the expression as (a * b) == 0 due to TER and
during expansion we can query target costs and adjust the initial RTL we
generate.
As you note another alternative would be simplify-rtx. As with the
expansion approach we'd need to query the target costs.
For the expansion approach you also have to balance generating
t = (a == 0) || (b == 0)
if (t) ...
against using multiple branches. But otherwise it's likely straight
forward.
In the simplify-rtx approach you have to generate a single hunk of RTL
and I highly suspect that's not likely to match anything. At best
you're hoping that you rewrite into the preferred form and that combine
then splits the complex RTL into sensible hunks and can recognize the
components after splitting. So it's got less of a chance of just working.
jeff
