Details
- Reviewers
tony-tye dblaikie • tstellarAMD aprantl arsenm - Commits
- rG2b4917fcc95b: [DebugInfo] Append extended dereferencing mechanism to variables' DIExpression…
rC297397: [DebugInfo] Append extended dereferencing mechanism to variables' DIExpression…
rL297397: [DebugInfo] Append extended dereferencing mechanism to variables' DIExpression…
Diff Detail
Event Timeline
lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
3351 | Is this hook necessary? Can you just not append if the returned address space is the default, or do we want to be explicit even with private address space? |
lib/Basic/Targets.cpp | ||
---|---|---|
2275 | Is this necessary? Or could it be done only when the address space is non-zero (so the getTargetAddressspace would be called unconditionally, if the result is non-zero add the addr space xderef thing)? |
lib/Basic/Targets.cpp | ||
---|---|---|
2275 | I had the same thought. I think the question is what assumption can be made about the consumer of the DWARF. I do not think DWARF requires that an omitted address space should be treated as 0, so if a target chooses not to do so then omitting the address space is not necessarily the same as generating a 0 address space. At least always generating them is safe! Another issue is what the consumer of the DWARF requires. For AMDGPU address space 0 is private since alloca allocates space in the per-thread address space. To support address spaces the debugger needs a core address that can access any of the address spaces, which would be the generic address space. The XDREF is telling the debugger to do the affect of an address space cast, which is needed to map from the private address space to the generic address space. So omitting it would prevent the target specific mapping to happen. Another observation is that the target specific address space numbering in LLVM need not necessarily be the address class/address space numbering in DWARF. So should there be a mapping function? If such a function existed, then the target could define DWARF address space 0 to be generic (and so need no conversion) and then address class and XDREF could be omitted for DWARF address class/space 0 (which for AMDGPU would not map to LLVM address space 0). |
It would also be good if we could leave open the possibility of decoupling LLVM address space 0 from OpenCL private address space. I would like to be able to someday be able to change that
lib/Basic/Targets.cpp | ||
---|---|---|
2275 | Missing override. |
lib/Basic/Targets.cpp | ||
---|---|---|
2275 |
For the out-of-tree target I'm involved with, this is the case. |
Address review feedback
lib/Basic/Targets.cpp | ||
---|---|---|
2275 | Added a function for mapping LLVM AS -> DWARF AS. | |
lib/CodeGen/CGDebugInfo.cpp | ||
3187 | I have currently changed it to SmallVectorImpl. I am not sure if MutableArrayRef should be used here? What if we decide to add more expressions before appending address space xderef? | |
3351 | We want to be explicit about private and lds. | |
test/CodeGenOpenCL/debugger-amdgpu-variable-locations.cl | ||
49 | Fixed. Thanks. |
lib/CodeGen/CGDebugInfo.cpp | ||
---|---|---|
3187 | SmallVectorImpl is fine. |
Is this necessary? Or could it be done only when the address space is non-zero (so the getTargetAddressspace would be called unconditionally, if the result is non-zero add the addr space xderef thing)?