https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108787
--- Comment #9 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #7) > Created attachment 54460 [details] > gcc13-pr108787.patch That patch is preapproved, but please add a comment (before umaddditi4) saying we do not want maddditi4 as well (and why; just something short, maybe reference this PR :-) ) Thanks! > Patch that kills maddditi4 in addition to fixing umaddditi4. As mentioned > above, in the umaddditi4 case if we later on e.g. during combine find out > that > the high half of the last operand is zero, it will be nicely optimized to > the optimal sequence. Unfortunately, with maddditi4 it is really hard to > find out at expansion time if the last operand is sign extended from DImode > or narrower, > there is no SSA_NAME on the pseudo to check say for value ranges, and > looking at earlier already emitted instructions checking for one subreg of > it set to something and the other to copies of its sign bit would be a total > mess. > And at combine time I'm afraid we'd need 5 instruction combination. > So if we want to be able to optimize qux above, I'm afraid we'd need to add > a new optab. It is easy to optimise if operands[3] is a non-negative 64-bit thing. I expect combine can do it in that case :-)
