[llvm] [LV] Keep duplicate recipes in VPExpressionRecipe (PR #156976)
Sam Tebbs via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 24 05:31:03 PDT 2025
SamTebbs33 wrote:
> > Sorry, it doesn't just impact printing, but anything that wants to analyse the recipes at all, such as bundled partial reductions: https://github.com/llvm/llvm-project/pull/147302/files#diff-34abe4c3cd34aa7a9664bbd204834248455635ba80b8a9ba9506d8c3e6b94d95R2878
>
> But can't this also be avoided naturally, by just getting the needed extend from the reduction/result recipe which is the root of the pattern, instead of relying on a specific order of operands? In the future, the operands to a reduction pattern could also contain live-ins (e.g. constant), and in that case there would be be no recipe at all.
>
> > I don't quite see why it's bad to get the recipe list correct from the very beginning?
>
> I guess it depends on what 'correct' means here. Currently it is simply the list of recipes that are bundled together.
>
> > At the moment only the destructor needs to know that ExpressionRecipes contains duplicates when deleting them. What other complexity is required with regards to handling duplicates?
>
> 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.
The problem with checking the root instruction is that you'll have to repeat the pattern matching that was already done in the transform pass. Whereas with this solution you can rely on them being in the recipe list so can fetch them from there, without re-doing any work. With Sander's placeholder caching suggestion, the code has become a lot simpler so I hope that's acceptable.
https://github.com/llvm/llvm-project/pull/156976
More information about the llvm-commits
mailing list