[VPlan] Initial modeling of runtime VF * UF as VPValue.

[fhahn]

Summary

This patch starts initial modeling of runtime VF * UF in VPlan.
Initially, introduce a dedicated RuntimeVFxUF VPValue, which is then
populated during VPlan::prepareToExecute. Initially, the runtime
VF * UF applies only to the main vector loop region. Once we extend the
scope of VPlan in the future, we may want to associate different VFxUFs
with different vector loop regions (e.g. the epilogue vector loop)

This allows explicitly parameterizing recipes that rely on the runtime
VF * UF, like the canonical induction increment. At the moment, this
mainly helps to avoid generating some duplicated calls to vscale with
scalable vectors. It should also allow using EVL as induction increments
explicitly in D99750. Referring to VF * UF is also needed in other
places that we plan to migrate to VPlan, like the minimum trip count
check during skeleton creation.

The first version creates the value for VF * UF directly in
prepareToExecute to limit the scope of the patch. A follow-on patch will
model VF * UF computation explicitly in VPlan using recipes.

Note: Not all tests have been updated yet. I will update the remaining
tests once we are happy with the overall structure of the patch.

[ABataev]

llvm/lib/Transforms/Vectorize/VPlan.h

2560

const member function

[fhahn]

Update printing of CanonicalIVIncrement to print both operands.

[fhahn]

llvm/lib/Transforms/Vectorize/VPlan.h

2560

Unfortunately this causes problems with various users which expect non-const return value.

[ABataev]

llvm/lib/Transforms/Vectorize/VPlan.h

2560

But can you return non-const return value but using const function?
Like

VPValue &getRuntimeVFxUF() const {return RuntimeVFxUF;}

[nikolaypanchenko]

llvm/lib/Transforms/Vectorize/VPlan.h

2479

might be better to clarify that it's loop invariant VPValue.
With @ABataev patch in, we may followup to unify EVL and RuntimeVFxUF. Does it sound reasonable ?

[fhahn]

llvm/lib/Transforms/Vectorize/VPlan.h

2479

might be better to clarify that it's loop invariant VPValue.

Updated, thanks!

With @ABataev patch in, we may followup to unify EVL and RuntimeVFxUF. Does it sound reasonable ?

Sounds good. I think another suggestion/option that @Ayal had was to keep the canonical induction increment fixed (incrementing by a variable value would make it non-canonical) to control the loop and use EVL to only control the lanes accessed by (vector) recipes.

2560

Unfortunately this yields the following error as this would return a mutable reference to a member of a const pointer.

llvm/lib/Transforms/Vectorize/VPlan.h:2560:45: error: binding reference of type 'VPValue' to value of type 'const VPValue' drops 'const' qualifier
  VPValue &getRuntimeVFxUF() const { return RuntimeVFxUF; }
                                            ^~~~~~~~~~~~

[fhahn]

Update comment to state that RuntimeVFxUF is loop-invariant.

[nikolaypanchenko]

llvm/lib/Transforms/Vectorize/VPlan.h

2479

Can you please elaborate needs of having canonical loop form out of the vectorizer ?