<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Hi, <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="mso-fareast-language:EN-US">the IR comes from clang in -O0 form. So no optimizations are performed by the front-end. The IR goes through a backend agnostic preparation phase that brings
it into SSA from and changes the AS from 0 to 1. After this phase the IR goes through another pass manager that performs O3 passes and the AMDGPU target passes for object file generation. I looked into the AMDGPU backend and the only place where this metadata
is added is in A</span><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black">MDGPUAnnotateUniformValues.cpp. The pass queries dependency analysis for the load and checks if it is reported as uniform. Afterwards the metadata is added to
the GEP. <o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black">Removing the O3 passes before code generation solves the problem so does separating the O3 passes and the backend passes into separate
pass managers. I assume dependency analysis does not run in the second pass manager because no metadata is generated at all.
<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black">Could this be a bug in DA reporting the load falsely as uniform by not taking the intrinsics into account?<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black">Cheers,
<o:p></o:p></span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.5pt;font-family:Consolas;color:black">Michael<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></span>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>Von:</b> Matt Arsenault [mailto:whatmannerofburgeristhis@gmail.com]
<b>Im Auftrag von </b>Matt Arsenault<br>
<b>Gesendet:</b> Dienstag, 5. <span lang="EN-US">Dezember 2017 20:01<br>
<b>An:</b> Haidl, Michael <michael.haidl@uni-muenster.de><br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Betreff:</b> Re: [llvm-dev] [AMDGPU] Strange results with different address spaces<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US">On Dec 5, 2017, at 13:53, Matt Arsenault <</span><a href="mailto:arsenm2@gmail.com"><span lang="EN-US">arsenm2@gmail.com</span></a><span lang="EN-US">> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US">On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <</span><a href="mailto:llvm-dev@lists.llvm.org"><span lang="EN-US">llvm-dev@lists.llvm.org</span></a><span lang="EN-US">> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi dev list, <br>
<br>
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>
<br>
Here is the IR is attached as as1.ll<br>
<br>
The output is as follows: <br>
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<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">It looks like the addressing in as1.ll is incorrectly concluded to be uniform:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> %6 = tail call i32 @llvm.amdgcn.workitem.id.x() #0, !range !11<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> %7 = tail call i32 @llvm.amdgcn.workgroup.id.x() #0<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> %mul.i.i.i.i.i = mul nsw i32 %7, %3<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64 %idxprom.i.i.i, !amdgpu.uniform !12, !amdgpu.noclobber !12<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">However since this depends on </span><a href="http://workitem.id/"><span lang="EN-US">workitem.id</span></a><span lang="EN-US">.x, it certainly is not<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">-Matt<o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal">-Matt<o:p></o:p></p>
</div>
</div>
</body>
</html>