[PATCH] D148906: [AMDGPU] Remove incompatible attributes of function in amdgpu-remove-incompatible-functions pass

Yaxun Liu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 24 06:33:30 PDT 2023


yaxunl added a comment.

In D148906#4289053 <https://reviews.llvm.org/D148906#4289053>, @JonChesterfield wrote:

> In D148906#4287243 <https://reviews.llvm.org/D148906#4287243>, @yaxunl wrote:
>
>> device libs may be linked in by other programs or libraries, e.g. comgr.
>
> That used to be broken. Clang mlink-builtin-bitcode applies attributes to functions in device libs that were both required and missing from device libs. Caused a bunch of pain in openmp because we really wanted to link device libs at link time, not into every TU up front in clang. Has someone fixed that requirement?

OpenCL uses  AMDGPUSimplifyLibCalls with -amdgpu-prelink, which transforms some calls of device lib functions into calls of new device lib functions, e.g. sincos. Since this happens after clang's -mlink-builtin-bitcode, these newly introduced device lib functions need to be linked in by comgr directly.

But that is not the only situation that device libs are linked by non-clang programs. There are other FE's that generate IR for amdgpu and need link with device libs, e.g. XLA.

That said, I think the question is that whether simply removing `+wavefrontsize32` makes a function valid for wave64. There must be a reason that a function in device lib is marked with `+wavefrontsize32`. I assume that a function marked with `+wavefrontsize32` means it can only be used with wave32. If that is true, then such functions should just be treated as incompatible functions and treated the same way.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148906/new/

https://reviews.llvm.org/D148906



More information about the llvm-commits mailing list