Reserve R9 on armv6 iOS 2.x

[Un1q32]

The iOS 2.x ABI had R9 as a reserved register, 3.0 made it available, but support for the 2.x ABI was never added to LLVM. We only use the 2.x ABI on armv6 since before 3.0 armv6 was the only architecture supported by iOS.

[llvmbot]

@llvm/pr-subscribers-backend-arm

Author: None (Un1q32)

Changes

The iOS 2.x ABI had R9 as a reserved register, 3.0 made it available, but support for the 2.x ABI was never added to LLVM. We only use the 2.x ABI on armv6 since before 3.0 armv6 was the only architecture supported by iOS.

---

Full diff: https://github.com/llvm/llvm-project/pull/150835.diff

1 Files Affected:

• (modified) llvm/lib/Target/ARM/ARMSubtarget.cpp (+4-1)

diff --git a/llvm/lib/Target/ARM/ARMSubtarget.cpp b/llvm/lib/Target/ARM/ARMSubtarget.cpp
index 9f600e0c685ab..d6e226736ba66 100644
--- a/llvm/lib/Target/ARM/ARMSubtarget.cpp
+++ b/llvm/lib/Target/ARM/ARMSubtarget.cpp
@@ -227,7 +227,10 @@ void ARMSubtarget::initSubtargetFeatures(StringRef CPU, StringRef FS) {
       (Options.UnsafeFPMath || isTargetDarwin()))
     HasNEONForFP = true;
 
-  if (isRWPI())
+  if (isRWPI() ||
+      (isTargetIOS() &&
+       ARM::parseArch(TargetTriple.getArchName()) == ARM::ArchKind::ARMV6K &&
+       TargetTriple.isOSVersionLT(3, 0)))
     ReserveR9 = true;
 
   // If MVEVectorCostFactor is still 0 (has not been set to anything else), default it to 2

[Un1q32]

Should probably be armv6 and armv6k actually.

[Un1q32]

All armv6 iOS devices were armv6k, and clang -target armv6-apple-ios2 uses armv6k, but llc -mtriple=armv6-apple-ios2 doesn't so catching armv6 should help anyone running llc like that.

[jroelofs]

I haven't done the "archaeology" to check this, but it seems fine: IIUC the worst case fallout is that this hurts performance on a no-longer-supported platform, and best case is that it fixes this bug... so the tradeoff seems fine in light of that.

[Un1q32]

I haven't done the "archaeology" to check this, but it seems fine: IIUC the worst case fallout is that this hurts performance on a no-longer-supported platform, and best case is that it fixes this bug... so the tradeoff seems fine in light of that.

I actually have the hardware to test with, and I've been carrying this patch for a while in my personal clang builds. Without it anything non-trivial segfaults, and with it everything works. I can probably find where this is done in the old Apple GCC sources and link that here.

[Un1q32]

https://github.com/apple-oss-distributions/gcc/blob/24a5ff4087d09b1170bc4653c85bf2d8361b2320/gcc/config/arm/darwin.h#L291
https://github.com/apple-oss-distributions/gcc/blob/24a5ff4087d09b1170bc4653c85bf2d8361b2320/gcc/config/arm/arm.c#L23855
https://github.com/apple-oss-distributions/gcc/blob/24a5ff4087d09b1170bc4653c85bf2d8361b2320/gcc/ChangeLog.apple#L387

[Un1q32]

I don't have merge access btw so I would appreciate it if someone else could merge this for me.