[PATCH] D98491: [AMDGPU] Split GCN subtarget features for unaligned access

Mahesha S via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 23 10:05:12 PDT 2021


hsmhsm added a comment.

In D98491#2645085 <https://reviews.llvm.org/D98491#2645085>, @hsmhsm wrote:

> In D98491#2644858 <https://reviews.llvm.org/D98491#2644858>, @rampitec wrote:
>
>> In D98491#2643944 <https://reviews.llvm.org/D98491#2643944>, @hsmhsm wrote:
>>
>>> @mbrkusanin
>>> My proposal was simple: prefer ds_read2_b64 (and write) over b128 if alignment < 16. I never heard of b64 performance issues though, so the rest is the same as now: create a widest load/store possible with that one exception for b128.
>>
>> We have since then confirmed that ds_read_b64 has the same performance hit on memory not aligned to 64 bit, so 64 bit operations too need an alignment check.
>
> But I see the below ISel pattern for - `DS_READ_B64` indeed checks alignment requirment, though not sure if it is  over written some where else.
>
> DSInstructions.td:717-719
>
>   foreach vt = VReg_64.RegTypes in {
>   defm : DSReadPat_mc <DS_READ_B64, vt, "load_align8_local">;
>   }

And further based on a closer look at the code, I think, in general, we better revert the commit 0654ff703d4e99423133165db63083b831efb9b6 <https://reviews.llvm.org/rG0654ff703d4e99423133165db63083b831efb9b6> in order to avoid above performance issues because of unligned access.  But, I am not aware of the consequences of reverting this patch.

@mbrkusanin / @foad What is your openion on reverting the patch 0654ff703d4e99423133165db63083b831efb9b6 <https://reviews.llvm.org/rG0654ff703d4e99423133165db63083b831efb9b6>?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98491



More information about the llvm-commits mailing list