The HardwareLoops pass finds exit blocks with a scevable exit count. If the target specifies to update the loop counter in a register, through a phi, we need to ensure that the exit block is a latch so that we can insert the phi with the correct value for the incoming edge.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/HardwareLoops.cpp | ||
---|---|---|
247 ↗ | (On Diff #204773) | Maybe "RequiresLoopExitingLatch" as a more descriptive name? |
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
706 ↗ | (On Diff #204773) | Is it worth just checking for the LoopExitingLatch here, as opposed to adding a parameter for it? (Put another way, why would one be a parameter and the other be something for the backend to figure out?) |
Cheers Dave. I've removed the ExitBlock check in the ARM backend. Also, currently we'd need CounterInReg == RequiresLoopLatchExit so I've just switched to querying CounterInReg instead of introducing a new parameter. If, later, there's another target which has a separate requirement, then we can re-add the option.
Am I correct in saying that this loop will find the first exiting block that dominates all the latches in the loop (with some other conditions like a loop invariant non zero exit count). Plus is now also a latch?
But the loop may have other exits and other latches?
The "other exits" sounds like it should be OK for arm low overhead loops. At least I can't think of a reason right now why they are not OK. For vector tail predicated loops I imagine that you would need to ensure that a "LCTP" is placed on the other exits, to ensure the tail predicate doesn't pollute extra instructions after the loop.
I'm not sure about the "other latches" part. Is that something that's OK? I imagine it doesn't come up very often.
Actually, looking at it, because we can compute the BETC, we will only have a single latch. Ignore me about that bit.
For scalar low overhead loops, this LGTM. Vector loops we are looking into later, as far as I understand.