https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Sun, 7 Dec 2025, gjl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360 > > --- Comment #7 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- > (In reply to Jeffrey A. Law from comment #6) > > For AVR a sequence using shifts is bad > > and the variant with MUL is even worse. It's so bad that I added stuff in the > avr backend that try to hack around PR118360 / PR118012. So to see whether > any > changes will improve the situation for avr and have any effect, you'll have to > compile with -mno-pr118012 in order to turn off these hacks. > > It's still beyond me why the root cause isn't fixed, that is: Transformations > in match.pd that is not optimizations, not a canonicalization, that cannot be > rolled back due to its structure, and that cannot be turned off by some target > means. IMO all of those transforms should think twice about applying to modes bigger than word_mode, at least operations that have "word-crossing" effects. Meaning bit operations should be fine in general, but shifts not, multiplication depend on target support, etc. We might be able to assume there's a carry so shifts by 1 or add/sub might be fine. If there's specific patterns problematic on AVR and I see a patch that's adding sth like && known_le (GET_MODE_SIZE (TYPE_MODE (type)), GET_MODE_SIZE (word_mode)) I'd be inclined to approve it (hint!), at least it would be a good starting point for discussions. We could abstract this to a target hook with the above being the default implementation.
