> Date: Sun, 30 Aug 2026 11:16:33 -0600 > From: Jeff Law <[email protected]>
> On 8/30/26 8:53 AM, Hans-Peter Nilsson wrote: > >> Date: Sat, 29 Aug 2026 00:43:27 -0600 > >> Cc: [email protected] > >> From: Jeff Law <[email protected]> > >> On 8/27/26 3:13 PM, Hans-Peter Nilsson wrote: > >>> Let's harmonize canonicalization for NOT-on-ROTATE and NOT-on-ROTATERT > >>> with that of BSWAP and BITREVERSE, and document the canonical > >>> form. Tested cross to cris-elf, native on x86_64-pc-linux-gnu. > >>> > >>> Ok to commit? > >>> > >>> brgds, H-P > >>> > >>> -- >8 -- > >>> Before this patch, the combine pass would match (bitreverse:SI (not:SI > >>> reg)) but not (rotate:SI (not:SI reg (const_int 16)))), instead > >>> requiring (not:SI (rotate:SI reg (const_int 16))) for the compound > >>> operation to be recognized. That looked inconsistent considering that > >>> both are bit-rearrangement operations commutative with bitwise negation. > >>> > >>> I was about to write "operations with which bitwise negation is > >>> commutative", but thought better list the operations explicitly. > >>> > >>> * doc/md.texi (Insn Canonicalizations): Document BITREVERSE, > >>> BSWAP, ROTATE, and ROTATERT as having the canonical form of > >>> NOT moved inside the first operand. > >>> * simplify-rtx.cc (simplify_context::simplify_unary_operation_1): > >>> Move a NOT to the inside of ROTATE and ROTATERT, like for BITREVERSE > >>> and BSWAP. > >>> * config/cris/cris.md (*rotsi2_16_not<setcc><setnz><setnzvc>): Adjust > >>> accordingly. > >> OK > > Thanks! Unfortunately, there's fallout on aarch64-unknown-linux-gnu, > > as "[email protected]" informed me, so there'll be a v2, but just > > with an added aarch64 MD patch with a similar correction as with > > cris.md. > Yea, but I consider this kind of fallout minor and not unexpected given > the nature of the change. We fix and move on. TL;DR: patch retracted for now. Thanks for the review but sorry Jeff, I prefer not to regress other targets. I did the pattern tweaking for aarch64, but that wasn't sufficient and I just don't have the incentive for further target tweaking for *this* particular issue, for now. The fallout is expected to be overwhelming (admittedly it doesn't take much though), according to Sashiko and friends: a patch I prepared to adjust aarch64.md is insufficient as there's more fallout: for arm32 too, with not only patterns but also cost functions needing non-obvious tweaks (and also making a pattern in avr redundant and no longer matching). Too much for my "that looks weird, let's fix it" tickle. (Sashiko 0.9.3 found only the aarch64 issues even though I raised its limits. Bare gemini-4-argon with a trivial "please review the last two commits" found the others. Tsk Tsk.) brgds, H-P PS. Not an endorsement for gemini-4-argon. Used as was Sashiko's default.
