[PATCH] D156928: [Clang][AMDGPU] Fix handling of -mcode-object-version=none arg

Yaxun Liu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Aug 4 15:16:00 PDT 2023


yaxunl added a comment.

In D156928#4562023 <https://reviews.llvm.org/D156928#4562023>, @yaxunl wrote:

> In D156928#4561890 <https://reviews.llvm.org/D156928#4561890>, @JonChesterfield wrote:
>
>> In D156928#4561849 <https://reviews.llvm.org/D156928#4561849>, @arsenm wrote:
>>
>>> In D156928#4561811 <https://reviews.llvm.org/D156928#4561811>, @JonChesterfield wrote:
>>>
>>>> What does code objects version= none mean?
>>>
>>> Handle any version
>>
>> So... That should be the default, right? Emit IR that the back end specialises. Or, ideally, the only behaviour as far as the front end is concerned.
>
> Code in the device library depends on a control variable about the code object version. Specifying the code object version in Clang allows internalizing that variable and optimizing code depending on it as early as possible. Not specifying it with Clang will require an LLVM pass in amdgpu backend to define that control variable after linking and it has to have an external linkage. This may lose optimization. Also, you need a way to not specify it in FE but specify it in BE. This just complicates things without much benefits.

On second thoughts, this may inspire us about eliminating not just the code object control variable but all device library control variables.

Basically in Clang we can emit a module flag about required control variables and do not link the device libs that implement these control variables.

Then we add an LLVM pass at the very beginning of the optimization pipeline which checks that module flag and defines those control variables with internal linkage. This way, we should be able to get rid of those control variable device libs without losing performance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156928



More information about the cfe-commits mailing list