https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121738
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2025-12-08
Ever confirmed|0 |1
--- Comment #1 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Note that for RISC-V if you turn on the "b" extensions you get good code for
all three initial testcases:
11 0000 33F5A540 andn a0,a1,a0
12 0004 13351500 seqz a0,a0
13 0008 8280 ret
"b" is part of the rva23 profile and I would expect it to be commonplace in
designs going forward.
But without "b" we don't optimize as well as we should.
Interestingly enough we can see that combine realizes the forms are the same,
even without the "b" extension as it tries:
(set (reg:DI 146 [ _4 ])
(eq:DI (and:DI (not:DI (reg:DI 147 [ x ]))
(reg:DI 148 [ y ]))
(const_int 0 [0])))
For the different testcases. But without "b" that's not a viable combination
and no rewriting is down as the compressability of instructions isn't really
known to GCC at all. So there's nothing to trigger trying to rewrite one form
into another.
We could look at this as a canonicalization problem up in gimple and pick a
form. The biggest problem I see with that is any form we choose is somewhat
arbitrary and may work well for one target, but not for others.
Overall point being I'm not sure what the path forward ought to be here and
it's not even clear it's worth a lot of time, at least on the RISC-V side.
