[llvm] SimplifyLibCalls: Use default globals address space when building new global strings. (PR #118729)
Eli Friedman via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 5 15:03:11 PST 2024
================
@@ -0,0 +1,35 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; Test that the printf library call simplifier works correctly.
+;
+; RUN: opt < %s -passes=instcombine -S | FileCheck %s
+
+target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128-G200"
+
+ at hello_world = addrspace(200) constant [13 x i8] c"hello world\0A\00"
+ at percent_s = addrspace(200) constant [4 x i8] c"%s\0A\00"
+
+declare i32 @printf(ptr addrspace(200) , ...)
+declare i32 @puts(ptr addrspace(200))
----------------
efriedma-quic wrote:
The problem with *not* having `TargetLibraryInfo::getVoidPtrTy()` is that you accidentally inherit information from other places. If the source of that inheritance is other C library functions, you're fine, I guess, but that's extremely hard to audit. For example, you call emitPutS() with a pointer with address-space getDefaultGlobalsAddressSpace(). Is that right? We don't know, and nothing will ever check it.
I don't think having a separate source of truth for getVoidPtrTy() is really a big deal compared to all the other assumptions that TargetLibraryInfo makes. We can make clang codegen check that the TargetLibraryInfo is correct if you're concerned it'll fall out of sync somehow.
https://github.com/llvm/llvm-project/pull/118729
More information about the llvm-commits
mailing list