[mac/lld] Fix scale computation for vector ops in PAGEOFF12 relocations

[thakis]

Summary

With this, llvm-tblgen no longer tries and fails to allocate 7953 petabyte
when it runs during the build. Instead, check-llvm with lld/mac as host
linker now completes without any failures on an m1 mac.

This vector op handling code matches what happens in:

• ld64's OutputFile::applyFixUps() in OutputFile.cpp for kindStoreARM64PageOff12
• lld.ld64.darwinold's offset12KindFromInstruction() in lld/lib/ReaderWriter/MachO/ArchHandler_arm64.cpp for offset12scale16
• RuntimeDyld's decodeAddend() in llvm/lib/ExecutionEngine/RuntimeDyld/Targets/RuntimeDyldMachOAArch64.h for ARM64_RELOC_PAGEOFF12

Fixes PR49444.

[thakis]

lld/MachO/Arch/ARM64.cpp

130–137

(the type change in this line is inconsequential. All callers pass a uint32_t, it's conceptually a uint32_t, and on the return line it gets widened to an uin64_t. This part is a no-op, but it seemed semantically more correct -- without it, you'd technically have to do (base >> 30) & 3 if you didn't know that all callers passed in a widened uint32_t.)

[int3]

Nice fix!

lld/MachO/Arch/ARM64.cpp

132

TIL that C++ has digit separators

[smeenai]

lld/MachO/Arch/ARM64.cpp

134

If I'm reading the encoding table right (downloaded from https://developer.arm.com/documentation/ddi0487/ga/), then yup, this means a 128-bit operation.

[int3]

lld/MachO/Arch/ARM64.cpp

134

I interpreted the question mark as "here we are checking if we have a vector op", not "I'm not entirely sure this is a vector op"... but I guess it's a bit confusing since line 132 doesn't have a question mark

[thakis]

lld/MachO/Arch/ARM64.cpp

134

Yes, that's how I meant it. This is "C7.2.191 LDR (immediate, SIMD&FP)" in the ARM ARM, "128-bit variant Applies when size == 00 && opc == 11."

I have to say I find https://developer.arm.com/documentation/ddi0487/ga/ pretty hard to read though. I ended up writing myself a decoder (first few lines of https://github.com/nico/mra_tools) to help me navigate that PDF. Maybe there's some easier way to answer "given 32-bit aarch64 instruction, find out what exactly it means", but that script works for me now that I've written it :)

[thakis]

lld/MachO/Arch/ARM64.cpp

134

I replaced the comment with "128-bit variant" in 7d26916859e9. That's the language used in the ARM ARM, and there are only 42 hits for that in it, and searching for that in it finds the relevant bits. Hopefully that's a less confusing comment :)

[smeenai]

lld/MachO/Arch/ARM64.cpp

134

Thanks!

lld/MachO/Arch/ARM64.cpp

inline uint64_t encodePage21(uint64_t base, uint64_t va) {
   return (base | bitField(va, 12, 2, 29) | bitField(va, 14, 19, 5));
 }
 
 //                      21                   10
 // +-------------------+-----------------------+-------------------+
 // |                   |         imm12         |                   |
 // +-------------------+-----------------------+-------------------+
 
-inline uint64_t encodePageOff12(uint64_t base, uint64_t va) {
-  int scale = ((base & 0x3b000000) == 0x39000000) ? base >> 30 : 0;
+inline uint64_t encodePageOff12(uint32_t base, uint64_t va) {
+  int scale = 0;
+  if ((base & 0x3b00'0000) == 0x3900'0000) { // load/store
+    scale = base >> 30;
+    if (scale == 0 && (base & 0x0480'0000) == 0x0480'0000) // vector op?
+      scale = 4;
+  }
+
   // TODO(gkm): extract embedded addend and warn if != 0
   // uint64_t addend = ((base & 0x003FFC00) >> 10);
   return (base | bitField(va, scale, 12 - scale, 10));
 }
 
 inline uint64_t pageBits(uint64_t address) {
   const uint64_t pageMask = ~0xfffull;
   return address & pageMask;

lld/test/MachO/arm64-relocs.s

 # CHECK-DAG:   [[#%x,BAZ:]]   g     O __DATA,__data _baz
 
 # CHECK-LABEL: _foo:
 ## BRANCH26 relocations are 4-byte aligned, so 123 is truncated to 120
 # CHECK-NEXT:  bl 0x[[#BAR+120]]
 ## PAGE21 relocations are aligned to 4096 bytes
 # CHECK-NEXT:  adrp x2, [[#]] ; 0x[[#BAZ+4096-128]]
 # CHECK-NEXT:  ldr  x2, [x2, #128]
+# CHECK-NEXT:  adrp     x3, 8 ; 0x8000
+# CHECK-NEXT:  ldr      q0, [x3, #144]
 # CHECK-NEXT:  ret
 
 # CHECK-LABEL: Contents of (__DATA_CONST,__const) section
 # CHECK:       [[#PTR_1]] {{0*}}[[#BAZ]]     00000000 00000000 00000000
 # CHECK:       [[#PTR_2]] {{0*}}[[#BAZ+123]] 00000000 00000000 00000000
 
 .text
-.globl _foo, _bar, _baz
+.globl _foo, _bar, _baz, _quux
 .p2align 2
 _foo:
   ## Generates ARM64_RELOC_BRANCH26 and ARM64_RELOC_ADDEND
   bl _bar + 123
   ## Generates ARM64_RELOC_PAGE21 and ADDEND
   adrp x2, _baz@PAGE + 4097
   ## Generates ARM64_RELOC_PAGEOFF12
   ldr x2, [x2, _baz@PAGEOFF]
+
+  ## Generates ARM64_RELOC_PAGE21
+  adrp x3, _quux@PAGE
+  ## Generates ARM64_RELOC_PAGEOFF12 with internal slide 4
+  ldr q0, [x3, _quux@PAGEOFF]
   ret
 
 .p2align 2
 _bar:
   ret
 
 .data
 .space 128
 _baz:
 .space 1
 
+.p2align 4
+_quux:
+.quad 0
+.quad 80
+
 .section __DATA_CONST,__const
 ## These generate ARM64_RELOC_UNSIGNED symbol relocations. llvm-mc seems to
 ## generate UNSIGNED section relocations only for compact unwind sections, so
 ## those relocations are being tested in compact-unwind.s.
 _ptr_1:
   .quad _baz
   .space 8
 _ptr_2:
   .quad _baz + 123
   .space 8
 
 .subsections_via_symbols