From aca8f327137ab6fdec17310ca201860151d4f808 Mon Sep 17 00:00:00 2001 From: Krzysztof Parzyszek Date: Fri, 6 Apr 2018 18:13:11 +0000 Subject: [PATCH] [Hexagon] Prevent a stall across zero-latency instructions in a packet Packetizer keeps two zero-latency bound instrctions in the same packet ignoring the stalls on the later instruction. This should not be the case if there is no data dependence. Patch by Sumanth Gundapaneni. llvm-svn: 329437 --- .../Target/Hexagon/HexagonVLIWPacketizer.cpp | 31 ++++++++++--------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/llvm/lib/Target/Hexagon/HexagonVLIWPacketizer.cpp b/llvm/lib/Target/Hexagon/HexagonVLIWPacketizer.cpp index ac232d414f4d6..f8cfa09baba18 100644 --- a/llvm/lib/Target/Hexagon/HexagonVLIWPacketizer.cpp +++ b/llvm/lib/Target/Hexagon/HexagonVLIWPacketizer.cpp @@ -1807,17 +1807,18 @@ bool HexagonPacketizerList::producesStall(const MachineInstr &I) { SUnit *SUI = MIToSUnit[const_cast(&I)]; - // Check if the latency is 0 between this instruction and any instruction - // in the current packet. If so, we disregard any potential stalls due to - // the instructions in the previous packet. Most of the instruction pairs - // that can go together in the same packet have 0 latency between them. - // Only exceptions are newValueJumps as they're generated much later and - // the latencies can't be changed at that point. Another is .cur - // instructions if its consumer has a 0 latency successor (such as .new). - // In this case, the latency between .cur and the consumer stays non-zero - // even though we can have both .cur and .new in the same packet. Changing - // the latency to 0 is not an option as it causes software pipeliner to - // not pipeline in some cases. + // If the latency is 0 and there is a data dependence between this + // instruction and any instruction in the current packet, we disregard any + // potential stalls due to the instructions in the previous packet. Most of + // the instruction pairs that can go together in the same packet have 0 + // latency between them. The exceptions are + // 1. NewValueJumps as they're generated much later and the latencies can't + // be changed at that point. + // 2. .cur instructions, if its consumer has a 0 latency successor (such as + // .new). In this case, the latency between .cur and the consumer stays + // non-zero even though we can have both .cur and .new in the same packet. + // Changing the latency to 0 is not an option as it causes software pipeliner + // to not pipeline in some cases. // For Example: // { @@ -1830,10 +1831,10 @@ bool HexagonPacketizerList::producesStall(const MachineInstr &I) { for (auto J : CurrentPacketMIs) { SUnit *SUJ = MIToSUnit[J]; for (auto &Pred : SUI->Preds) - if (Pred.getSUnit() == SUJ && - (Pred.getLatency() == 0 || HII->isNewValueJump(I) || - HII->isToBeScheduledASAP(*J, I))) - return false; + if (Pred.getSUnit() == SUJ) + if ((Pred.getLatency() == 0 && Pred.isAssignedRegDep()) || + HII->isNewValueJump(I) || HII->isToBeScheduledASAP(*J, I)) + return false; } // Check if the latency is greater than one between this instruction and any