[llvm] [IPO] Added attributor for identifying invariant loads (PR #141800)

[Krzysztof Drewniak via llvm-commits]

================
@@ -0,0 +1,220 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 5
+; RUN: opt -passes=attributor %s -S | FileCheck %s
+
+ at G = global i32 zeroinitializer, align 4
+
+declare ptr @get_ptr()
+declare noalias ptr @get_noalias_ptr()
+
+define i32 @test_plain(ptr %ptr) {
+; CHECK-LABEL: define i32 @test_plain(
+; CHECK-SAME: ptr nofree noundef nonnull readonly align 4 captures(none) dereferenceable(4) [[PTR:%.*]]) #[[ATTR0:[0-9]+]] {
+; CHECK-NEXT:    [[VAL:%.*]] = load i32, ptr [[PTR]], align 4
+; CHECK-NEXT:    ret i32 [[VAL]]
+;
+  %val = load i32, ptr %ptr, align 4
+  ret i32 %val
+}
+
+define i32 @test_noalias_ptr(ptr noalias %ptr) {
+; CHECK-LABEL: define i32 @test_noalias_ptr(
+; CHECK-SAME: ptr noalias nofree noundef nonnull readonly align 4 captures(none) dereferenceable(4) [[PTR:%.*]]) #[[ATTR0]] {
+; CHECK-NEXT:    [[VAL:%.*]] = load i32, ptr [[PTR]], align 4, !invariant.load [[META0:![0-9]+]]
----------------
krzysz00 wrote:

Hm, yeah, then a lack of atomic access to a thing is also important

... Right, so the one case is spin-waiting on a flag that some other device (the host, say), will set, which might still _look_ `readonly noalias` but shouldn't be invariant.

... Actually, no, if you're doing that, I think you want to be volatile on top of being atomic? My recollection of pointer semnatics is that "load from a location I never write whose value mysteriously changes" needs to be volatile.

So I think we're clear to mark non-volatile loads invariant if they meet the other conditions, because if you're doing atomic-y things, you'll either have a code path that writes the location or you need to be volatile.

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