[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