[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. User Guide for AMDGPU Backend — LLVM 15.0.0git documentation 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

as1.ll (3.91 KB)

as0.ll (3.88 KB)

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

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.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

Hi,

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 AMDGPUAnnotateUniformValues.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.

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.

Could this be a bug in DA reporting the load falsely as uniform by not taking the intrinsics into account?

Cheers,

Michael

The IR goes through a backend agnostic preparation phase that brings it into SSA from and changes the AS from 0 to 1.

This sounds possibly problematic to me. The IR should be created with the correct address space to begin with. Changing this in the middle sounds suspect.

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 AMDGPUAnnotateUniformValues.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.

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.

Could this be a bug in DA reporting the load falsely as uniform by not taking the intrinsics into account?

Cheers,
Michael

The intrinsics certainly are correctly treated as divergent. Nothing would work otherwise. If I run the annotate pass or analysis on the examples it does the right thing and sees the load as divergent.

$ opt -S -analyze -divergence -o - as1.ll
Printing analysis 'Divergence Analysis' for function '_ZN5pacxx2v213genericKernelIZL12test_barrieriPPcE3$_0EEvT_':
DIVERGENT: %6 = tail call i32 @llvm.amdgcn.workitem.id.x() #0, !range !11
DIVERGENT: %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6
DIVERGENT: %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64
DIVERGENT: %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64 %idxprom.i.i.i
DIVERGENT: %9 = load i32, i32 addrspace(1)* %8, align 4
DIVERGENT: %10 = getelementptr [16 x i32], [16 x i32] addrspace(3)* @"_ZN5pacxx2v213genericKernelIZL12test_barrieriPPcE3$_0EEvT__sm0", i32 0, i32 %6
DIVERGENT: store i32 %9, i32 addrspace(3)* %10, align 4
DIVERGENT: %11 = load i32, i32 addrspace(3)* %10, align 4
DIVERGENT: %12 = getelementptr i32, i32 addrspace(1)* %callable.coerce1, i64 %idxprom.i.i.i
DIVERGENT: store i32 %11, i32 addrspace(1)* %12, align 4

I’m also questioning how/where you obtained this dump. You have the declarations for the control flow intrinsics in there, which should only ever appear when the backend inserts them as part of codegen. There’s something suspicious about your pass setup. What does the IR look like immediately before AMDGPUAnnotateUniformValues, and immediately out of the frontend?

-Matt

Hi Matt,

thanks for your response. I agree that the IR should be generated with the correct AS in the first place. However, for my project this is somehow impossible. I need the same IR with everything in AS 0 for CPU execution and again with GPU specific address spaces to avoid performance impacts of the generic address space. Doing this in the front-end means a way more intrusive change to clang and a way I did not want to go in the first place.

I have the IR that goes into the pass manager attached to the mail.

The PM is set up as follows:

llvm::TargetOptions options;

options.UnsafeFPMath = false;

options.NoInfsFPMath = false;

options.NoNaNsFPMath = false;

options.HonorSignDependentRoundingFPMathOption = false;

options.AllowFPOpFusion = FPOpFusion::Fast;

Triple TheTriple = Triple(M.getTargetTriple());

std::string Error;

SmallString<128> hsaString;

llvm::raw_svector_ostream hsaOS(hsaString);

if (!_target)

_target = TargetRegistry::lookupTarget(“amdgcn”, TheTriple, Error);

if (!_target) {

throw common::generic_exception(Error);

}

llvm::legacy::PassManager PM;

PassManagerBuilder builder;

builder.OptLevel = 3;

builder.populateModulePassManager(PM);

_machine.reset(_target->createTargetMachine(

TheTriple.getTriple(), _cpu, _features, options, Reloc::Model::Static,

CodeModel::Model::Medium, CodeGenOpt::Aggressive));

if (_machine->addPassesToEmitFile(PM, hsaOS,

TargetMachine::CGFT_ObjectFile, false)) {

throw std::logic_error(

“target does not support generation of this file type!\n”);

}

PM.run(M);

The IR from the original post was dumped after PM has finished its work because I could not figure out where the problem arises with just the IR before the PM starts working. Running opt with -O3 on the IR does not change much in the IR and on both versions of the IR I get the same output you did in your first response.

DIVERGENT: %6 = tail call i32 @llvm.amdgcn.workitem.id.x() #0

DIVERGENT: %add.i.i.i.i.i = add nsw i32 %mul.i.i.i.i.i, %6

DIVERGENT: %idxprom.i.i.i = sext i32 %add.i.i.i.i.i to i64

DIVERGENT: %8 = getelementptr i32, i32 addrspace(1)* %callable.coerce0, i64 %idxprom.i.i.i

DIVERGENT: %9 = load i32, i32 addrspace(1)* %8, align 4

DIVERGENT: %10 = getelementptr [16 x i32], [16 x i32] addrspace(3)* @"_ZN5pacxx2v213genericKernelIZL12test_barrieriPPcE3$_0EEvT__sm0", i32 0, i32 %6

DIVERGENT: store i32 %9, i32 addrspace(3)* %10, align 4

DIVERGENT: %11 = load i32, i32 addrspace(3)* %10, align 4

DIVERGENT: %12 = getelementptr i32, i32 addrspace(1)* %callable.coerce1, i64 %idxprom.i.i.i

DIVERGENT: store i32 %11, i32 addrspace(1)* %12, align 4

I cannot see where these uniform access comes into play.

Cheers,

Michael

final.ll (3.02 KB)

final_O3.ll (2.8 KB)

Hi Matt,

thanks for your response. I agree that the IR should be generated with the correct AS in the first place. However, for my project this is somehow impossible.

I need the same IR with everything in AS 0 for CPU execution and again with GPU specific address spaces to avoid performance impacts of the generic address space.

We have an optimization pass to eliminate generic accesses, so for the most part you shouldn’t have to worry about this too much. You can insert casts to flat and generally expect them to be eliminated. This is what HCC is doing now.

Doing this in the front-end means a way more intrusive change to clang and a way I did not want to go in the first place.

I have the IR that goes into the pass manager attached to the mail.
The PM is set up as follows:

  llvm::TargetOptions options;
  options.UnsafeFPMath = false;
  options.NoInfsFPMath = false;
  options.NoNaNsFPMath = false;
  options.HonorSignDependentRoundingFPMathOption = false;
  options.AllowFPOpFusion = FPOpFusion::Fast;

  Triple TheTriple = Triple(M.getTargetTriple());
  std::string Error;
  SmallString<128> hsaString;
  llvm::raw_svector_ostream hsaOS(hsaString);
  if (!_target)
    _target = TargetRegistry::lookupTarget("amdgcn", TheTriple, Error);
  if (!_target) {
    throw common::generic_exception(Error);
  }

  llvm::legacy::PassManager PM;
  PassManagerBuilder builder;
  builder.OptLevel = 3;
  builder.populateModulePassManager(PM);

  _machine.reset(_target->createTargetMachine(
      TheTriple.getTriple(), _cpu, _features, options, Reloc::Model::Static,
      CodeModel::Model::Medium, CodeGenOpt::Aggressive));

  if (_machine->addPassesToEmitFile(PM, hsaOS,
                                    TargetMachine::CGFT_ObjectFile, false)) {
    throw std::logic_error(
        "target does not support generation of this file type!\n");
  }

  PM.run(M);
<>

I can’t see what’s going on with this. I would look into what happens when AMDGPUTTIImpl::isSourceOfDivergence is called in your broken example. I don’t see exactly how it would happen or how it would cause this, but I”m guessing something went wrong where the wrong address space mapping is being used at some point.

-Matt