AMDGPUAnnotateKernelFeatures should be deleted

[arsenm]

This infers the "amdgpu-calls" and "amdgpu-stack-objects" attributes, which are poorly named and handled backwards. We only use these to try to infer whether we need to initialize flat scratch. Instead, we should use AMDGPUAttributor and infer a amdgpu-no-flat-scratch-init on kernels. We really want to detect whether any private addresses could potentially be addrspacecasted to flat.

[llvmbot]

@llvm/issue-subscribers-backend-amdgpu

[jdoerfert]

private addresses could potentially be addrspacecasted to flat

So to detect if private addresses = AS(5) pointers(?) could be casted to AS(0)?

[arsenm]

So to detect if private addresses = AS(5) pointers(?) could be casted to AS(0)?

Yes. Might as well consider AS(5) to anything and presume anything else is some future software used pointer tagging

[arsenm]

I think this is easy enough by extending the existing code in checkForQueuePtr. My main question is whether we should bother checking for constant expression addrspacecasts. The two possible cases are private globals (illegal and unhandled) and casts from integer literals (do we care about allowing assuming a 0 pointer points to something specific in the future?)

[nhaehnle]

inttoptr in general we want to support, I think. We do have some plans for using part of the wave scratch for non-stack purposes. It would then be a bit inconsistent to handle an inttoptr instruction but not an inttoptr constant expression.

[arsenm]

inttoptr in general we want to support, I think. We do have some plans for using part of the wave scratch for non-stack purposes. It would then be a bit inconsistent to handle an inttoptr instruction but not an inttoptr constant expression.

But are you allowed to address a defined object that way? The constant doesn't really have provenance. That would have to be something that isn't program visible

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Assign the issue to you.
2. Fix the issue locally.
3. Run the test suite locally.
   3.1) Remember that the subdirectories under test/ create fine-grained testing targets, so you can
   e.g. use make check-clang-ast to only run Clang's AST tests.
4. Create a git commit
5. Run git clang-format HEAD~1 to format your changes.
6. Submit the patch to Phabricator.
   6.1) Detailed instructions can be found here

For more instructions on how to submit a patch to LLVM, see our documentation.

If you have any further questions about this issue, don't hesitate to ask via a comment on this Github issue.

@llvm/issue-subscribers-good-first-issue

[kzhuravl]

Need to re-assign to Jun.

[jwanggit86]

Is this just a matter of negating the adding of the AMDGPUAnnotateKernelFeature pass, or is there anything else required? Thanks!

[jwanggit86]

@arsenm The function AMDGPUAnnotateKernelFeatures::addFeatureAttributes() goes through the instructions to look for alloca and call instructions. However, there's a comment in the function that says this is a "poor way" to infer whether there are calls. So I wonder what's a better way to do this? Also what about stack objects, if not looking for alloca?