Haidl, Michael via llvm-dev
2017-Dec-05 07:51 UTC
[llvm-dev] [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>
Tom Stellard via llvm-dev
2017-Dec-05 18:36 UTC
[llvm-dev] [AMDGPU] Strange results with different address spaces
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 >
Matt Arsenault via llvm-dev
2017-Dec-05 18:53 UTC
[llvm-dev] [AMDGPU] Strange results with different address spaces
> 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 240It 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>
Matt Arsenault via llvm-dev
2017-Dec-05 19:01 UTC
[llvm-dev] [AMDGPU] Strange results with different address spaces
> 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 > > -MattActually 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>