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

via llvm-commits llvm-commits at lists.llvm.org
Wed May 6 23:33:14 PDT 2026


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

>From b8689a3e8a3ed2ba27ae9612f911ee98563d4517 Mon Sep 17 00:00:00 2001
From: Firebear518 <phj040518 at gmail.com>
Date: Thu, 7 May 2026 15:05:13 +0900
Subject: [PATCH] [Docs] Warn against extremely wide integer types in
 PerformanceTips

Several passes have super-linear complexity in bit width, and the
generated code is often sub-par as well. Advise frontends to avoid
extremely wide integer types.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply at anthropic.com>
---
 llvm/docs/Frontend/PerformanceTips.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index a11c8e3a16857..6efe17bc2e8c4 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/docs/Frontend/PerformanceTips.rst
@@ -157,6 +157,10 @@ As a result, alignment is mandatory for atomic loads and stores.
 Other Things to Consider
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
+#. Avoid emitting extremely wide integer types. The optimizer is not designed
+   for types exceeding a few thousand bits; several passes have super-linear
+   complexity, and the generated code is often sub-par as well.
+
 #. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing
    analysis), prefer GEPs
 



More information about the llvm-commits mailing list