[PATCH] D55814: GlobalISel: Support narrowing zextload/sextload

Daniel Sanders via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 18 10:43:01 PST 2019


dsanders added inline comments.
Herald added a subscriber: volkan.


================
Comment at: lib/CodeGen/GlobalISel/LegalizerHelper.cpp:526
+    auto &MMO = **MI.memoperands_begin();
+    if (MMO.getSize() * 8 == NarrowSize) {
+      MIRBuilder.buildLoad(TmpReg, PtrReg, MMO);
----------------
arsenm wrote:
> aemerson wrote:
> > Is this really needed?
> I’m not sure what you mean? Otherwise you’ll end up with an extload with the same source and dest size (which I think the verifier should reject)
I agree the verifier should reject it. 's32 = G_ZEXTLOAD ... :: (load 4 from ...)' isn't exactly wrong but it serves no purpose compared to 's32 = G_LOAD ... :: (load 4 from ...)'


================
Comment at: lib/CodeGen/GlobalISel/LegalizerHelper.cpp:540
+    else
+      MIRBuilder.buildSExt(DstReg, TmpReg);
+
----------------
However, this should be invalid for the same reason, 's32 = G_SEXT s32' doesn't make sense. It would be better for the case where it lowers to G_LOAD to just replace the opcode in place. If we have observers plumbed into the legalizer yet we should also call the changingInstr()+changedInstr() events.


================
Comment at: lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp:210
+  ExtLoads.clampScalar(0, S32, S32)
+          .widenScalarToNextPow2(0)
+          .unsupportedIfMemSizeNotPow2()
----------------
This is redundant given that clampScalar() limits the type to exactly s32. It's nice for consistency but it costs a small amount of compile-time to perform the test.


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

https://reviews.llvm.org/D55814





More information about the llvm-commits mailing list