Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 25 Dec 2021 11:56:25 GMT
From:      Dimitry Andric <dim@FreeBSD.org>
To:        src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-branches@FreeBSD.org
Subject:   git: 9b7616cc4748 - stable/12 - Fix "Bad machine code" when building world for mips or mips64
Message-ID:  <202112251156.1BPBuPs4007462@gitrepo.freebsd.org>

next in thread | raw e-mail | index | archive | help
The branch stable/12 has been updated by dim:

URL: https://cgit.FreeBSD.org/src/commit/?id=9b7616cc4748d228caa645d1af344febde04d584

commit 9b7616cc4748d228caa645d1af344febde04d584
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-10-18 14:50:24 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-12-25 11:51:39 +0000

    Fix "Bad machine code" when building world for mips or mips64
    
    Merge commit f5755c0849a5 from llvm git (by Jessica Clarke):
    
      [Mips] Add glue between CopyFromReg, CopyToReg and RDHWR nodes for TLS
    
      The MIPS ABI requires the thread pointer be accessed via rdhwr $3, $r29.
      This is currently represented by (CopyToReg $3, (RDHWR $29)) followed by
      a (CopyFromReg $3). However, there is no glue between these, meaning
      scheduling can break those apart. In particular, PR51691 is a report
      where PseudoSELECT_I was moved to between the CopyToReg and CopyFromReg,
      and since its expansion uses branches, it split the def and use of the
      physical register between two basic blocks, resulting in the def being
      eliminated and the use having no def. It also seems possible that a
      similar situation could arise splitting up the CopyToReg from the RDHWR,
      causing the RDHWR to use a destination register other than $3, violating
      the ABI requirement.
    
      Thus, add glue between all three nodes to ensure they aren't split up
      during instruction selection. No regression test is added since any test
      would be implictly relying on specific scheduling behaviour, so whilst
      it might be testing that glue is preventing reordering today, changes to
      scheduling behaviour could result in the test no longer being able to
      catch a regression here, as the reordering might no longer happen for
      other unrelated reasons.
    
      Fixes PR51691.
    
      Reviewed By: atanasyan, dim
    
      Differential Revision: https://reviews.llvm.org/D111967
    
    (cherry picked from commit 4e117af10caf2b6f95c7ef44b08aa7a812a37286)
---
 contrib/llvm-project/llvm/lib/Target/Mips/MipsSEISelDAGToDAG.cpp | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/contrib/llvm-project/llvm/lib/Target/Mips/MipsSEISelDAGToDAG.cpp b/contrib/llvm-project/llvm/lib/Target/Mips/MipsSEISelDAGToDAG.cpp
index 7be5fc33a0af..04a835f08855 100644
--- a/contrib/llvm-project/llvm/lib/Target/Mips/MipsSEISelDAGToDAG.cpp
+++ b/contrib/llvm-project/llvm/lib/Target/Mips/MipsSEISelDAGToDAG.cpp
@@ -1027,12 +1027,13 @@ bool MipsSEDAGToDAGISel::trySelect(SDNode *Node) {
     }
 
     SDNode *Rdhwr =
-        CurDAG->getMachineNode(RdhwrOpc, DL, Node->getValueType(0),
+        CurDAG->getMachineNode(RdhwrOpc, DL, Node->getValueType(0), MVT::Glue,
                                CurDAG->getRegister(Mips::HWR29, MVT::i32),
                                CurDAG->getTargetConstant(0, DL, MVT::i32));
     SDValue Chain = CurDAG->getCopyToReg(CurDAG->getEntryNode(), DL, DestReg,
-                                         SDValue(Rdhwr, 0));
-    SDValue ResNode = CurDAG->getCopyFromReg(Chain, DL, DestReg, PtrVT);
+                                         SDValue(Rdhwr, 0), SDValue(Rdhwr, 1));
+    SDValue ResNode = CurDAG->getCopyFromReg(Chain, DL, DestReg, PtrVT,
+                                             Chain.getValue(1));
     ReplaceNode(Node, ResNode.getNode());
     return true;
   }



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202112251156.1BPBuPs4007462>