<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 5, 2017, at 13:53, Matt Arsenault <<a href="mailto:arsenm2@gmail.com" class="">arsenm2@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi dev list, <br class=""><br class="">I am currently exploring the integration of AMDGPU/ROCm into the PACXX project and observing some strange behavior of the AMDGPU backend. The following IR is generated for a simple address space test that copies from global to shared memory and back to global after a barrier synchronization. <br class=""><br class="">Here is the IR is attached as as1.ll<br class=""><br class="">The output is as follows: <br class="">0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 48 48 48 48 48 48 48 48 48 48 48 48 48 48 48 48 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112 112 128 128 128 128 128 128 128 128 128 128 128 128 128 128 128 128 144 144 144 144 144 144 144 144 144 144 144 144 144 144 144 144 160 160 160 160 160 160 160 160 160 160 160 160 160 160 160 160 176 176 176 176 176 176 176 176 176 176 176 176 176 176 176 176 192 192 192 192 192 192 192 192 192 192 192 192 192 192 192 192 208 208 208 208 208 208 208 208 208 208 208 208 208 208 208 208 224 224 224 224 224 224 224 224 224 224 224 224 224 224 224 224 240 240 240 240 240 240 240 240 240 240 240 240 240 240 240 240<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">It looks like the addressing in as1.ll is incorrectly concluded to be uniform:</div><div class=""><br class=""></div></div><div class=""> %6 = tail call i32 @llvm.amdgcn.workitem.id.x() #0, !range !11</div><div class=""> %7 = tail call i32 @llvm.amdgcn.workgroup.id.x() #0</div><div class=""> %mul.i.i.i.i.i = mul nsw i32 %7, %3</div><div class=""> %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6</div><div class=""> %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64</div><div class=""> %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64 %idxprom.i.i.i, !amdgpu.uniform !12, !amdgpu.noclobber !12</div><div class=""><br class=""></div><div class="">However since this depends on <a href="http://workitem.id/" class="">workitem.id</a>.x, it certainly is not</div><div class=""><br class=""></div><div class="">-Matt</div></div></div></blockquote></div><br class=""><div class="">Actually you have the amdgpu.uniform annotation already here, and it isn’t added by the backend optimization pass, so there’s a bug in however you produced this. It just happens the uniform load optimization doesn’t trigger on flat loads.</div><div class=""><br class=""></div><div class="">-Matt</div></body></html>