[llvm] [VPlan] Consistently use (Part, 0) for first lane scalar values (PR #80271)

via llvm-commits llvm-commits at lists.llvm.org
Sun Feb 18 06:10:48 PST 2024


ayalz wrote:

> > > Perhaps it is the "other recipes" who should be fixed, to more consistently store their single scalar in per-part storage rather than lane zero? The current design of State is to hold UF per-part Values whenever possible, be they vectors or (uniform) scalars, and otherwise holds VF*UF per-lane Values, for every VPValue. The hasVectorValue() and hasScalarValue() indicators should better be renamed hasValuePerPart() and hasValuePerLane(), respectively.
> > 
> > 
> > That would be another option, but a potential problem could be recipes that only have their first lane used, but one of their operands would only define a vector value per-part. With this patch, this will work as accessing the per-lane value will create an extract from the per-part vector.
> 
> Would it be better to stick with the current design, and fix such cases of missing extracts?
> 

Ahh, only other recipe that may generate uniform(-"after-vectorization") scalar values besides VPInstruction is Replicate recipe - which already stores its scalar in lane zero rather than per-part...

OK, let's go with storing values-per-part in lane-zero, consistently. Suggest to wrap in a `State.get(VPValue *value, unsigned part, bool IsScalarPerPart)` API to make it clearer and easier to change later.

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


More information about the llvm-commits mailing list