[llvm] SimplifyLibCalls: Use default globals address space when building new global strings. (PR #118729)

[Jessica Clarke via llvm-commits]

================
@@ -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))
----------------
jrtc27 wrote:

This also shows up in atomic libcall handling. I don't really care whether it's called the "libcalls address space", "C ABI address space", "default address space" or some other thing like that, but it's a long-standing issue that LLVM only has the fine-grained definition-based address spaces (alloca, global, program) but no use-based / generic address spaces beyond 0, which CHERI backends do not use for various technical reasons (whether that's the right choice is a different matter, but this should be possible to do). I've always felt there should be some sort of `-D<address space>` (if using "default" above) which is the address space of a pointer without any further context, and is what you can then map C's `T *` to. A `-L<address space>` for libcalls might be fine, though I'd be concerned it's still overly narrow.

@resistor Please tag @arichardson and myself on future CHERI-related PRs. Between us we have a lot of experience with CHERI LLVM and I want to ensure you're making upstream changes we agree with rather than going behind our backs. It was a surprise to me at least that these PRs had been filed and merged.

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