[llvm] [InstCombine] Implement processSMulSExtIdiom for Signed Multiplication Overflow Detection (PR #131461)

[Craig Topper via llvm-commits]

topperc wrote:

To add to the bigger picture here. Historically the backends had problems supporting smul.overflow. SelectionDAG could only handle smul.overflow on types that fit in a legal register size. Or maybe twice the size of a legal register. There were also some cases that would call a library function that only exists in compiler-rt and not libgcc.

umul.overflow was better supported in the backend.

I don't think any of the broken cases were reachable from software using builtins like __builtin_smul_overflow and the middle end would never create smul.overflow.

35fa7b8ad83e6cddb38190818df3c6688b3c2313 from 3.5 years ago started creating smul.overlow in the middle end. That spawned these patches to prevent calls to non-existant library functions. 124bcc1a139d744a71a82a89e90b5058573f2697, c1a31ee65b3a2bf2b452febb99703b3fdfa43328, 39e5dd113f5c00de21f8071142fccbb5e08025e7, d0eeb64be5848a7832d13db9d69904db281d02e8, e9b3f2573090a2fb9494975e4615f77b898e36a3, d8b6ae072d7734e2abadd54ecddfd6cb77b7e4c0, c8c176d999d2c2166dee8d67c32b4f8f42b4f1bd, 5c91b98c5d45243352bf10262454bcac77cd3fed. I created b2ca4dc935859b324fd7e9ca804160913a7468a5 to avoid crashes on large types, but it generates poor code. Earlier this year I created e30a4fc3e20bf5d9cc2f5bfcb61b4eb0e686a193 to improve the generated code for larger types.

So the situation in the backend has approved at lot in the last 3.5 years, but it is possible this patch causes someone to find a new backend issue.

https://github.com/llvm/llvm-project/pull/131461