[llvm] [PowerPC] 32-bit large code-model support for toc-data (PR #85129)

[Chen Zheng via llvm-commits]

================
@@ -1272,25 +1284,33 @@ void PPCAsmPrinter::emitInstruction(const MachineInstr *MI) {
     EmitToStreamer(*OutStreamer, TmpInst);
     return;
   }
+  case PPC::ADDItocL:
   case PPC::ADDItocL8: {
-    // Transform %xd = ADDItocL8 %xs, @sym
+    // Transform %xd = ADDItocL %xs, @sym
     LowerPPCMachineInstrToMCInst(MI, TmpInst, *this);
 
-    // Change the opcode to ADDI8. If the global address is external, then
-    // generate a TOC entry and reference that. Otherwise, reference the
-    // symbol directly.
-    TmpInst.setOpcode(PPC::ADDI8);
+    unsigned Op = MI->getOpcode();
+
+    // Change the opcode to load address for tocdata
+    TmpInst.setOpcode(Op == PPC::ADDItocL8 ? PPC::ADDI8 : PPC::LA);
 
     const MachineOperand &MO = MI->getOperand(2);
-    assert((MO.isGlobal() || MO.isCPI()) && "Invalid operand for ADDItocL8.");
+    if (Op == PPC::ADDItocL8)
+      assert((MO.isGlobal() || MO.isCPI()) && "Invalid operand for ADDItocL8.");
+    else
+      assert(MO.isGlobal() && "Invalid operand for ADDItocL.");
----------------
chenzheng1030 wrote:

> ADDItocL8 is already used on Linux medium code model for TOC access, so its possible that the MO is a CPI.

ADDItocL8 is used with CPI MO in global-isel when lowering a constant pool entry. But that is only for PPC64LE.

I originally thought ADDItocL should be used there for 32 bit. So maybe it is not strange that we use `ADDItocL` for CPI MO too. IIUC in the patch https://github.com/llvm/llvm-project/commit/34627e3434dbc8979218708ba4c4cf72f7c8e988 where `ADDItocL` was firstly introduced, there is no CPI MO usage for it.
But seems all 32-bit ABI(ELF32 and AIX32) does not allow direct access to TOC, so we should not use ADDItocL for 32bit, we should use LWZtocL.

I agree with you. We can limit ADDItocL to global address.

https://github.com/llvm/llvm-project/pull/85129