[llvm-dev] [Pipeliner] MachinePipeliner TargetInstrInfo hooks need more information?

[Krzysztof Parzyszek via llvm-dev]

Hi Luke,
The main why the pipeliner only looks for hardware loops on Hexagon is that a hardware loop instruction requires that the iteration count has been computed for the loop. In other words, if a loop has been converted to a hardware loop, then there is a virtual register that holds the iteration count (or the iteration count is a compile-time constant). For loops where the exit condition is recalculated at each iteration, determining the iteration count may be difficult (there is no equivalent of scalar evolution pass for MIR).
If your code can extend the functionality of the pipeliner to such loops, then your contributions would certainly be welcome.

-Krzysztof

cc: Brendon, who wrote the pipeliner.

________________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Lau, Luke via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Friday, May 10, 2019 2:50 AM
To: llvm-dev at lists.llvm.org
Cc: Verma, Saurabh
Subject: [EXT] [llvm-dev] [Pipeliner] MachinePipeliner TargetInstrInfo hooks need more information?

Hello,

I'm working on integrating the MachinePipeliner.cpp pass into our VLIW
backend, and so far we've managed to get it working with some nice
speedups.
Unlike Hexagon however, our backend doesn't generate hardware loop
instructions and so all our loops are a combination of induction
variables, comparisons and branches. So when it came to implementing
reduceLoopCount for our TargetInstrInfo, we found that we didn't have
enough information from analyzeLoop to reduce the loops.

Currently the signatures look like this:

   bool analyzeLoop(MachineLoop &L, MachineInstr *&IndVarInst,
                    MachineInstr *&CmpInst)

   unsigned TargetInstrInfo::reduceLoopCount(MachineBasicBlock &MBB,
         MachineInstr *IndVar,
         MachineInstr &Cmp,
         SmallVectorImpl<MachineOperand> &Cond,
         SmallVectorImpl<MachineInstr *> &PrevInsts,
         unsigned Iter,
         unsigned MaxIter) const

Since the condition operands for branching in our architecture are
found on the branch instruction and not the comparison instruction, we
weren't able to populate Cond in reduceLoopCount.

Furthermore, since some loops conditionally branched to exit the loop
whilst others conditionally branched to continue the loop, we sometimes
needed to invert these condition codes. (MachinePipeliner.cpp inserts
branches assuming that the Cond operands are the operands for *exiting*
the loop)

In the end we had to change the signatures to pass around a bit more
information:

    bool analyzeLoop(MachineLoop &L, MachineInstr *&IndVarInst,
                     MachineInstr *&CmpInst, MachineInstr *&BranchInst,
                     bool *BranchExits)

    unsigned reduceLoopCount(MachineBasicBlock &MBB,
        MachineInstr *IndVar,
        MachineInstr &Cmp,
        MachineInstr &Exit,
        bool BranchExits,
        SmallVectorImpl<MachineOperand> &Cond,
        SmallVectorImpl<MachineInstr *> &PrevInsts,
        unsigned Iter,
        unsigned MaxIter)

BranchInst allows us to get the operands required to pass back in Cond,
and BranchExits is set to true whenever the branch exits the loop, so
that we can then invert the condition if it doesn't exit the loop.

Would these changes be desirable upstream? As far as I'm aware Hexagon
doesn't use the IndVar instruction, and just passes along the hardware
loop instruction through CmpInst, so adapting it for this new API was
trivial.

Luke Lau
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev