[llvm] [LV] Keep duplicate recipes in VPExpressionRecipe (PR #156976)
Florian Hahn via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 23 01:50:13 PDT 2025
fhahn 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.
https://github.com/llvm/llvm-project/pull/156976
More information about the llvm-commits
mailing list