RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 10:42:39 +01:00
Code Issues Projects Releases Wiki Activity

[Hexagon] Prevent a stall across zero-latency instructions in a packet

Browse Source 
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
This commit is contained in:
Krzysztof Parzyszek 2018-04-06 18:13:11 +00:00
parent cbd3448493
commit e25a65a321
1 changed files with 16 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
lib/Target/Hexagon/HexagonVLIWPacketizer.cpp
View File

@ -1807,17 +1807,18 @@ bool HexagonPacketizerList::producesStall(const MachineInstr &I) {
SUnit *SUI = MIToSUnit[const_cast<MachineInstr *>(&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