[llvm] [VPlan] Initial modeling of runtime VF * UF as VPValue. (PR #74333)

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 7 12:47:05 PST 2023


fhahn wrote:


> Could this simply be an Add, whose restriction to Part0 is inferred by analysis, i.e., OnlyFirstPartUsed, analogous to OnlyFirstLaneUsed? Once unrolling takes place as a VPlan-to-VPlan transform, this distinction would vanish.
>

@ayalz Yep, that simplifies things. I moved the update to a new stacked PR which is #74761, based on  #74762, which just moves the insert point of the VF * UF computation to the preheader, to reduce the test changes in the later patch.

 
> Still wonder about the term "Runtime" in "RuntimeVFxUF"; the UF is always a compile-time constant, and VF is always a loop-invariant - either a compile-time constant (Fixed) or a runtime constant (Scalable). As opposed to a loop-variant runtime "EVL". See https://reviews.llvm.org/D157322 suggesting to call this VPValue "VectorStep", complementing "VectorTripCount", essentially referring to the loop's strip-mine factor?

Called it `VFxUF` for now in  #74761, but happy to adjust further once it's ready to go

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


More information about the llvm-commits mailing list