[llvm] [ModuloSchedule] Implement modulo variable expansion for pipelining (PR #65609)

[via llvm-commits]

================
@@ -748,6 +748,20 @@ class TargetInstrInfo : public MCInstrInfo {
     createTripCountGreaterCondition(int TC, MachineBasicBlock &MBB,
                                     SmallVectorImpl<MachineOperand> &Cond) = 0;
 
+    /// Create a condtion to determine if the remaining trip count represented
----------------
dpenry wrote:

I would prefer that a different method name be used for this new method.  The reason is that the assumptions of this variant of createTripCountGreaterCondition are **quite** different from those of the original function.

The original method is trying to create a comparison against the original trip counter coming into the loop and can assume that there is a reaching definition of that original trip counter at the end of MBB.  Some targets (PowerPC and ARM) actually ignore the TC in some circumstances because there is a further assumption that this function will be called to add comparisons at the end of prologue stages, so the TC which is wanted will always be "the right one" for the prologue stage.  This even permits pipelining of loops which don't really have a trip count.  The original method also can return whether the comparison is statically known to be taken or not taken, and the caller must make use of that.

The new method wants something different: it wants a comparison of how many iterations **remain** to  the desired TC value and thus requires that a register containing that remaining iteration count be passed in.  It doesn't worry about static comparisons -- in fact, the return value is ignored.  Thus it really should have a different name.  How about createRemainingIterationsGreaterCondition?  (That's a bit long, but it is descriptive).

It would be even nicer if this method could subsume the three that have been added.  As all that is done with getCounterInitReg is to just use it immediately as a call argument, and getCounterUpdatedReg is to look it up in a map and then use the result as a call argument, how about adding a map parameter to createRemainingIterationsGreaterCondition so that the target's override of the method can do the lookup.  If the map is empty, then the initial value can be used.  (That convention should then be documented.)
Another nice feature of this approach is that if non-virtual registers contain the loop count (as is the case with some targets), the conditions can still be properly generated.

I would also add another function which says whether MVE is supported by the target and call that at the appropriate place; this will prevent erroring out on a MVE-able loop when a target doesn't actually support it.

Finally, the convention has been to provide no default implementation for all the methods (with one exception); while maintaining the convention will require adding a dummy implementation to pipelining targets which won't support this kind of schedule expansion, it is probably better to stick with convention here.

https://github.com/llvm/llvm-project/pull/65609