[PATCH] D61259: AArch64: support arm64_32, an ILP32 slice for watchOS.

[Tim Northover via Phabricator via llvm-commits]

t.p.northover marked 7 inline comments as done.
t.p.northover added inline comments.


================
Comment at: llvm/lib/Target/AArch64/AArch64ISelLowering.cpp:3428
+    // Avoid copying a physreg twice since RegAllocFast is incompetent and only
+    // allows one use of a physreg per block.
+    SDValue Val = CopiedRegs.lookup(VA.getLocReg());
----------------
aemerson wrote:
> Why does this happen at all?
When lowering a return of (say) [2 x i32], the two components will get mapped to (X0, AExtUpper) and (X0, ZExt), a duplication of X0.


================
Comment at: llvm/test/CodeGen/AArch64/arm64-collect-loh.ll:163
 define i64 @getSExtInternalCPlus4() {
-  %addr = getelementptr i32, i32* @InternalC, i32 4
+  %addr = getelementptr inbounds i32, i32* @InternalC, i32 4
   %res = load i32, i32* %addr, align 4
----------------
aemerson wrote:
> Can you add a comment here explaining that inbounds is needed for arm64_32 to produce the same code.
I'd kind of prefer not to. It's incidental to this test but the main complication of arm64_32 CodeGen, so I don't think it's really what a random reader of this test is going to be looking for.


================
Comment at: llvm/test/CodeGen/AArch64/arm64-zero-cycle-zeroing.ll:22
 ; NONEFP: ldr h0,{{.*}}
-; NONEFP: fmov s1, wzr
-; NONEFP: fmov d2, xzr
-; NONEFP: movi{{(.16b)?}} v3{{(.2d)?}}, #0
-; NONE16: fmov h0, wzr
-; NONE16: fmov s1, wzr
-; NONE16: fmov d2, xzr
-; NONE16: movi{{(.16b)?}} v3{{(.2d)?}}, #0
+; NONEFP-DAG: fmov s1, wzr
+; NONEFP-DAG: fmov d2, xzr
----------------
aemerson wrote:
> It's odd that this test changed?
Yes, it's not needed now (I have no idea why it was) so I've reverted these changes.


================
Comment at: llvm/test/CodeGen/AArch64/arm64_32-neon.ll:6
+; CHECK: mov.d v0[0], v1[0]
+  %res = insertelement <2 x double> %vec, double %val, i32 0
+  ret <2 x double> %res
----------------
aemerson wrote:
> Is anything really expected to change with NEON & arm64_32?
Not to change particularly, but this is in some sense the parts of NEON that could be affected by arm64_32: ABI boundaries and load/store addressing-modes.

Testing it separately avoids duplicating the AArch64 tests that really aren't different (e.g. arithmetic) but still gives us the coverage.


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

https://reviews.llvm.org/D61259