https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64160
--- Comment #5 from Peter A. Bigot <pab at pabigot dot com> --- Thanks, Ulrich: that's a better explanation of what makes me uncomfortable with that part of the machine description. We have a complex split pattern that's the sole user of an idiosyncratic predicate. It supports a set of other patterns that are introduced with a comment starting with "we are playing a dangerous game with GCC here" and going on to suggest "we put in some hacks to fix the situations we found where it didn't work". It only works on SI, not QI (and yes people do use 64-bit integer operations on this target). It's only done for add, not subtract. It's not clear why subregs are to be excluded from the overall concept of eliminating partial results. Basically, the whole set of patterns exposing carry looks like an attempt to optimize what's produced by a specific source-level expression, instead of a carefully constructed transformation designed to match the capabilities of the target ISA. As MSP430 user I'd rather see it pulled and replaced with something simple that works even if it isn't optimal: in mspgcc I just generated an ADD (SUB) followed by a sequence of ADDC (SUBC) determined by operand size and that worked out fine. Fixing the inefficiencies described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64027 would provide more value than special-casing 32-bit add operations.
