[PATCH] D115661: [clang][amdgpu] - Choose when to promote VarDecl to address space 4.

Ethan Stewart via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Dec 14 13:53:17 PST 2021


estewart08 added a comment.

In D115661#3193157 <https://reviews.llvm.org/D115661#3193157>, @arsenm wrote:

> In D115661#3193152 <https://reviews.llvm.org/D115661#3193152>, @yaxunl wrote:
>
>> In D115661#3192983 <https://reviews.llvm.org/D115661#3192983>, @estewart08 wrote:
>>
>>> In D115661#3190477 <https://reviews.llvm.org/D115661#3190477>, @yaxunl wrote:
>>>
>>>> This may cause perf regressions for HIP.
>>>
>>> Do you have a test that would show such a regression? Emitting a store to address space (4) in a constructor seems the wrong thing to do.
>>
>> The two lit tests which changed from addr space 4 to 1 demonstrated that. In alias analysis, if a variable is in addr space 4, the backend knows that it is constant and can do optimizations on it. After changing to addr space 1, those optimizations are gone.
>
> The backend also knows because the constant flag is set on the global variable. Addrspace(4) is a kludge which is largely redundant with other mechanisms for indicating constants

If I am understanding you correctly, putting things in address space (4) has little to no performance benefit. @yaxunl seems to think otherwise. I agree that we can further constrain the address space (1) criteria, but I am getting conflicting viewpoints here on performance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115661



More information about the cfe-commits mailing list