Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release/20.x: [LAA] Consider accessed addrspace when mapping underlying obj to access. (#129087) #129317

Closed
wants to merge 1 commit into from

Conversation

fhahn
Copy link
Contributor

@fhahn fhahn commented Feb 28, 2025

Backport 275baed

In some cases, it is possible for the same underlying object to be accessed via pointers to different address spaces. This could lead to pointers from different address spaces ending up in the same dependency set, which isn't allowed (and triggers an assertion).

Update the mapping from underlying object -> last access to also include the accessing address space.

Fixes #124759.

PR: #129087

…ss. (llvm#129087)

In some cases, it is possible for the same underlying object to be
accessed via pointers to different address spaces. This could lead to
pointers from different address spaces ending up in the same dependency
set, which isn't allowed (and triggers an assertion).

Update the mapping from underlying object -> last access to also include
the accessing address space.

Fixes llvm#124759.

PR: llvm#129087
@llvmbot
Copy link
Member

llvmbot commented Feb 28, 2025

@llvm/pr-subscribers-llvm-analysis

Author: Florian Hahn (fhahn)

Changes

Backport 275baed

In some cases, it is possible for the same underlying object to be accessed via pointers to different address spaces. This could lead to pointers from different address spaces ending up in the same dependency set, which isn't allowed (and triggers an assertion).

Update the mapping from underlying object -> last access to also include the accessing address space.

Fixes #124759.

PR: #129087


Full diff: https://github.com/llvm/llvm-project/pull/129317.diff

2 Files Affected:

  • (modified) llvm/lib/Analysis/LoopAccessAnalysis.cpp (+8-4)
  • (added) llvm/test/Analysis/LoopAccessAnalysis/underlying-object-different-address-spaces.ll (+39)
diff --git a/llvm/lib/Analysis/LoopAccessAnalysis.cpp b/llvm/lib/Analysis/LoopAccessAnalysis.cpp
index 697b40403902c..dcd8a910d0f49 100644
--- a/llvm/lib/Analysis/LoopAccessAnalysis.cpp
+++ b/llvm/lib/Analysis/LoopAccessAnalysis.cpp
@@ -1283,8 +1283,10 @@ void AccessAnalysis::processMemAccesses() {
 
     bool SetHasWrite = false;
 
-    // Map of pointers to last access encountered.
-    typedef DenseMap<const Value*, MemAccessInfo> UnderlyingObjToAccessMap;
+    // Map of (pointer to underlying objects, accessed address space) to last
+    // access encountered.
+    typedef DenseMap<std::pair<const Value *, unsigned>, MemAccessInfo>
+        UnderlyingObjToAccessMap;
     UnderlyingObjToAccessMap ObjToLastAccess;
 
     // Set of access to check after all writes have been processed.
@@ -1364,12 +1366,14 @@ void AccessAnalysis::processMemAccesses() {
                     UnderlyingObj->getType()->getPointerAddressSpace()))
               continue;
 
+            unsigned AccessAS = cast<PointerType>(Ptr->getType())->getAddressSpace();
             UnderlyingObjToAccessMap::iterator Prev =
-                ObjToLastAccess.find(UnderlyingObj);
+                ObjToLastAccess.find({UnderlyingObj,AccessAS 
+                 });
             if (Prev != ObjToLastAccess.end())
               DepCands.unionSets(Access, Prev->second);
 
-            ObjToLastAccess[UnderlyingObj] = Access;
+            ObjToLastAccess[{UnderlyingObj, AccessAS}] = Access;
             LLVM_DEBUG(dbgs() << "  " << *UnderlyingObj << "\n");
           }
         }
diff --git a/llvm/test/Analysis/LoopAccessAnalysis/underlying-object-different-address-spaces.ll b/llvm/test/Analysis/LoopAccessAnalysis/underlying-object-different-address-spaces.ll
new file mode 100644
index 0000000000000..adf73c091be00
--- /dev/null
+++ b/llvm/test/Analysis/LoopAccessAnalysis/underlying-object-different-address-spaces.ll
@@ -0,0 +1,39 @@
+; NOTE: Assertions have been autogenerated by utils/update_analyze_test_checks.py UTC_ARGS: --version 5
+; RUN: opt -passes='print<access-info>' -disable-output %s 2>&1 | FileCheck %s
+
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128"
+
+; Test case for https://github.com/llvm/llvm-project/issues/124759. The same
+; underlying object is access through pointers with different address spaces.
+define void @same_underlying_object_different_address_spaces(ptr %dst1.as1, ptr %dst2.as1) {
+; CHECK-LABEL: 'same_underlying_object_different_address_spaces'
+; CHECK-NEXT:    loop:
+; CHECK-NEXT:      Report: cannot identify array bounds
+; CHECK-NEXT:      Dependences:
+; CHECK-NEXT:      Run-time memory checks:
+; CHECK-NEXT:      Grouped accesses:
+; CHECK-EMPTY:
+; CHECK-NEXT:      Non vectorizable stores to invariant address were not found in loop.
+; CHECK-NEXT:      SCEV assumptions:
+; CHECK-EMPTY:
+; CHECK-NEXT:      Expressions re-written:
+;
+entry:
+  %alloc = alloca i8, i64 0, align 128
+  %as3 = addrspacecast ptr %alloc to ptr addrspace(3)
+  %as4 = addrspacecast ptr %alloc to ptr addrspace(4)
+  br label %loop
+
+loop:
+  %iv = phi i64 [ 0, %entry ], [ %iv.next, %loop ]
+  store i32 0, ptr addrspace(4) %as4, align 4
+  store i32 0, ptr %dst1.as1, align 4
+  %l = load i64, ptr addrspace(3) %as3, align 4
+  store i64 %l, ptr %dst2.as1, align 4
+  %iv.next = add i64 %iv, 1
+  %c = icmp eq i64 %iv.next, 100
+  br i1 %c, label %loop, label %exit
+
+exit:
+  ret void
+}

@tstellar tstellar requested review from Meinersbur, david-arm and nikic and removed request for david-arm March 17, 2025 19:43
Copy link
Member

@Meinersbur Meinersbur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tstellar
Copy link
Collaborator

@fhahn Can you rebase this branch?

@tstellar
Copy link
Collaborator

Merged: 1515c4a

@tstellar tstellar closed this Mar 18, 2025
@fhahn fhahn deleted the issue124759 branch March 23, 2025 10:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

4 participants