[PATCH] D64899: AMDGPU/GlobalISel: First pass at attempting to legalize load/stores

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 24 11:20:52 PDT 2019


arsenm marked an inline comment as done.
arsenm added a comment.

In D64899#1597032 <https://reviews.llvm.org/D64899#1597032>, @nhaehnle wrote:

> Just to clarify, how is selection of global_load_ubyte and friends going to work? I assume similar to today where the load returns an s32 value, but instruction selection does matching based on the MemOperand remembering the size?


Yes, it's passed on the MMO size as it has always worked.

> Why are unaligned global loads split up on CI+? I see that you're trying to handle this in the code, but apparently it doesn't work correctly?

These are using mesa run lines. We only assume unaligned access is enabled for amdhsa (although I think the kernel hardcodes this). Most of the challenge of this patch is managing the number of combinations for the tests, so I'll go through all of these again eventually. I was working on a program to generate all of these, but then got tired of it



================
Comment at: lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp:549-550
+    case AMDGPUAS::CONSTANT_ADDRESS:
+    case AMDGPUAS::GLOBAL_ADDRESS:
+      return 512;
+    default:
----------------
nhaehnle wrote:
> Shouldn't the max size for global be 128? It only goes up to dwordx4.
It goes up to 512 for SMRD loads. Constant address space really doesn't exist. If the global load is uniform and constant, it can use an SMRD load. It will be split up during RegBankSelect


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

https://reviews.llvm.org/D64899





More information about the llvm-commits mailing list