llvm dev - Dec 2017 - [AMDGPU] Strange results with different address spaces

Hi dev list, 

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.

Here is the IR is attached as as1.ll

The output is as follows: 
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

However, the output should look like this: 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83
84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107
108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147
148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167
168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187
188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207
208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227
228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247
248 249 250 251 252 253 254 255

Which is produced by the IR in as0.ll

The only difference in the two IR dumps is that the parameters to the kernel are
in different address spaces.
https://llvm.org/docs/AMDGPUUsage.html#amdgpu-opencl states that address space 1
should be the global address space for amdgiz runtimes like ROCm and AS 0 is the
generic (flat) address space. Is this working as intended and do I something
wrong with the address spaces for AMDGPU or is this some undesired behavior and
a possible bug?

I am running the latest ROCm 1.6 on an AMD Vega RX 64 and llvm-trunk. 

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: as1.ll
Type: application/octet-stream
Size: 4008 bytes
Desc: as1.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/8d133f24/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: as0.ll
Type: application/octet-stream
Size: 3971 bytes
Desc: as0.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/8d133f24/attachment-0001.obj>

On 12/04/2017 11:51 PM, Haidl, Michael via llvm-dev
wrote:
> Hi dev list, 
> 
> 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.
> 
> Here is the IR is attached as as1.ll
> 
> The output is as follows: 
> 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
> 
> However, the output should look like this: 
> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54
55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81
82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105
106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125
126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145
146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165
166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185
186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205
206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225
226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245
246 247 248 249 250 251 252 253 254 255
> 
> Which is produced by the IR in as0.ll
> 
> The only difference in the two IR dumps is that the parameters to the
kernel are in different address spaces.
https://llvm.org/docs/AMDGPUUsage.html#amdgpu-opencl states that address space 1
should be the global address space for amdgiz runtimes like ROCm and AS 0 is the
generic (flat) address space. Is this working as intended and do I something
wrong with the address spaces for AMDGPU or is this some undesired behavior and
a possible bug?
> 
Can you post the clang invocations you used to generate these IR files?

-Tom
> I am running the latest ROCm 1.6 on an AMD Vega RX 64 and llvm-trunk. 
> 
> Cheers,
> Michael
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

> On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi dev list, 
> 
> 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.
> 
> Here is the IR is attached as as1.ll
> 
> The output is as follows: 
> 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
It looks like the addressing in as1.ll is incorrectly concluded to be uniform:

  %6 = tail call i32 @llvm.amdgcn.workitem.id.x() #0, !range !11
  %7 = tail call i32 @llvm.amdgcn.workgroup.id.x() #0
  %mul.i.i.i.i.i = mul nsw i32 %7, %3
  %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6
  %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64
  %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64
%idxprom.i.i.i, !amdgpu.uniform !12, !amdgpu.noclobber !12

However since this depends on workitem.id <http://workitem.id/>.x, it
certainly is not

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/3010afef/attachment.html>

> On Dec 5, 2017, at 13:53, Matt Arsenault <arsenm2 at gmail.com>
wrote:
> 
> 
> 
>> On Dec 5, 2017, at 02:51, Haidl, Michael via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Hi dev list, 
>> 
>> 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.
>> 
>> Here is the IR is attached as as1.ll
>> 
>> The output is as follows: 
>> 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
> 
> It looks like the addressing in as1.ll is incorrectly concluded to be
uniform:
> 
>   %6 = tail call i32 @llvm.amdgcn.workitem.id.x() #0, !range !11
>   %7 = tail call i32 @llvm.amdgcn.workgroup.id.x() #0
>   %mul.i.i.i.i.i = mul nsw i32 %7, %3
>   %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6
>   %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64
>   %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64
%idxprom.i.i.i, !amdgpu.uniform !12, !amdgpu.noclobber !12
> 
> However since this depends on workitem.id <http://workitem.id/>.x, it
certainly is not
> 
> -Matt
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.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171205/8a7e7c93/attachment.html>