[llvm] [LV] Keep duplicate recipes in VPExpressionRecipe (PR #156976)

[Florian Hahn via llvm-commits]

fhahn wrote:

> > Besides the descructor, decomposition and construction also need extra complexity. Granted it is not that much, but if looking up the required information from the root instruction works as well that may allow us to keep the generic code simpler.
> 
> I guess if you're reasoning from the idea that we'll only ever have this limited list of VPexpressions, then I guess this adds (marginally) more logic. But if we'd add a new expression that takes 4 external operands where expression recipes 0 and 1 could be the same, 1 and 2 could be the same, or 2 or 3 could be the same, or any other combination, then it would all get very confusing to figure out what the meaning of the values in `ExpressionRecipe` is. To me it therefore makes more sense for a VPExpression operation to always have the expected number of external operands and to take a little bit of care when needing to map that back to the expressions when decomposing in case there was a duplicate.

I would like to make sure the code we end up with is flexible enough to handle future use cases. At the moment, it looks like all the extends must be recipes, but they could also be constants that can be treated as extends in some case. If we want to support them, I assume we would be back to needing to check the root instruction? E.g. scaled reductions could have constant operands (https://github.com/llvm/llvm-project/pull/161092) and I would assume the same also holds for some of the other reduction patterns?

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