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

[Sander de Smalen via llvm-commits]

sdesmalen-arm wrote:

> I would like to make sure the code we end up with is flexible enough to handle future use cases w/o many changes.
> 
> One case I am wondering about is how we will handle cases where an interesting operand can be a recipe or a constant/live-in. At the moment, it looks like all 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, would be back to needing to check the root instruction? E.g. scaled reductions could have constant operands (#161092) and I would assume the same also holds for some of the other reduction patterns?

If we'd add a new VPExpression kind, then there's no need to change the VPExpression class or change the rest of the mechanism. That case could be supported quite easily with the help of this PR (I did an experiment with this locally to handle the case in #161092). A new constructor for that case is needed anyway and having it as a new expression kind makes it clear to handle these slightly differently (e.g. there's no need to query the opcode of the constant/live-in value).

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