[llvm] [ConstantRange] Bail out early in unsignedMulMayOverflow for wide integer types (PR #192275)

[Simon Pilgrim via llvm-commits]

================
@@ -83,6 +83,23 @@ There are some exceptions to this rule:
   they are commonly used in ``getelementptr`` instructions or attributes like
   ``sret``.
 
+Avoid extremely wide integer types
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Avoid using integer types with very large bit widths (e.g. ``i5754496``).
+LLVM's analysis and optimization passes operate on ``APInt`` values whose
+internal representation scales with bit width, and several algorithms have
+super-linear complexity in the number of 64-bit words required to represent the
+type. For example, overflow analysis, range intersection, and known-bits
+propagation can all be significantly slower for very wide types than for types
+that fit in one or two machine words.
+
+Practically speaking, types wider than a few thousand bits are unlikely to be
+optimized well and may cause compilation to hang or time out. If your language
+needs to represent very large integers, consider decomposing them into arrays or
+structs of machine-word-sized pieces and implementing big-integer arithmetic in
+IR rather than relying on LLVM's native arbitrary-width integer support.
----------------
RKSimon wrote:

This makes out the use of large types to be worse than they are - reduce this to a short statement and add it as an entry in "Other Things to Consider" below. 

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