[llvm] [ARM] support -mlong-calls -fPIC on arm32 #39970 (PR #147313)

[Peter Smith via llvm-commits]

================
@@ -2438,19 +2438,33 @@ ARMTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &CLI,
   auto PtrVt = getPointerTy(DAG.getDataLayout());
 
   if (Subtarget->genLongCalls()) {
-    assert((!isPositionIndependent() || TT.isOSWindows()) &&
-           "long-calls codegen is not position independent!");
     // Handle a global address or an external symbol. If it's not one of
     // those, the target's already in a register, so we don't need to do
     // anything extra.
+    bool isPIC = isPositionIndependent() && !TT.isOSWindows();
+
     if (isa<GlobalAddressSDNode>(Callee)) {
       if (Subtarget->genExecuteOnly()) {
+        // Execute-only forbids constant pools in .text, so use movw/movt.
+        // Note: execute-only may not support fPIC on ARM; this path is only
+        // reached for non-PIC targets.
         if (Subtarget->useMovt())
           ++NumMovwMovt;
         Callee = DAG.getNode(ARMISD::Wrapper, dl, PtrVt,
                              DAG.getTargetGlobalAddress(GVal, dl, PtrVt));
+      } else if (isPIC) {
+        // PIC without execute-only: use GOT-based addressing.
+        // DSO-local symbols use a plain PC-relative WrapperPIC;
+        // non-DSO-local symbols additionally load the address from the GOT.
+        SDValue G = DAG.getTargetGlobalAddress(
+            GVal, dl, PtrVt, 0, GVal->isDSOLocal() ? 0 : ARMII::MO_GOT);
+        Callee = DAG.getNode(ARMISD::WrapperPIC, dl, PtrVt, G);
+        if (!GVal->isDSOLocal())
+          Callee =
+              DAG.getLoad(PtrVt, dl, DAG.getEntryNode(), Callee,
+                          MachinePointerInfo::getGOT(DAG.getMachineFunction()));
       } else {
----------------
smithp35 wrote:

An assert isn't user-visible, as most users will be using a release build with no assertions.

I think the idea of an assert in the backend is that the front-end, which can give much better error messages does not generate LLVM-IR with these combinations.

For me, I would like to see a clang error message when there's a combination of -mlong-calls and execute-only (or ropi). There's also a per function attribute that would need to be checked https://clang.llvm.org/docs/AttributeReference.html#long-call-far  

Other than that, I'm OK when efreidma-quic, or possibly another backend maintainer, is happy with the code-generation.

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