https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981
--- Comment #12 from Jim Wilson <wilson at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #11) > (In reply to Jim Wilson from comment #9) > > This requires either a linux kernel longlong.h fix to use an alternate macro > > definition for mips targets that don't directly support TImode multiply. Or > > else it requires a gcc mips maintainer to fix the mips backend to add multi3 > > support for mips64r6. Either one should be possible by emitting two > > multiply instructions, one for the high part and one for the low part. > > The middle-end has support already for mult_highpart optab, low is the same > as mult optab (for the smaller mode), emitting this from the expr.c should > be easy to add rather than changing most of the back-ends to add a multi3 > optab. This is mips specific code in the kernel to do a multi3 (actually I think mulditi3). So this isn't a generic gcc problem affecting all targets. If you don't want the kernel doing this, then fix the kernel. The mips port already has a mulditi3 pattern, it is just lacking mips64r6 support. It looks like an oversight that should be fixed. You are right that expand_expr could synthesize a mulditi3 if muldi3_highpart is available, but it isn't clear if that is the right fix. Note that if we adopt this solution, then effectively you are forcing backends to implement a muldi3_highpart pattern. How is this any different than forcing them to implement a mulditi3 pattern? That doesn't make any sense. Also, note, that Jakub patch generates muldi3_highpart is mulditi3 fails. If we fix mulditi3 expansion to call muldi3_highpart, then that appears to make part of Jakub's patch unnecessary. I think it would be better to fix the mips mulditi3 pattern, or fix the kernel umul_ppmm macro to avoid the problem.
