search for: vprecipe

...ews.llvm.org/rL318645   Where We Are: ------------- With the first patch, we introduced the concept of VPlan to LV and started explicitly recording decisions like interleave memory access optimization and serialization. In the first patch, we resisted introducing VPInstructions ----- and introduced VPRecipes instead, in an attempt to avoid duplicating Instructions in the abstract HCFG Representation (i.e., abstract Instructions in HCFG that is separate from incoming IR Instructions). As we moved on, it became more and more apparent that we have a need to introduce new abstract Instructions (see https:...

Disclaimer: I haven’t been following this discussion closely, nor do I know what is going on in the modern AA/MemorySSA/GVN infra, but: I’d prefer to avoid abusing the Value* class hierarchy if reasonable. Adding new subclasses that only occur in special cases makes it more difficult to reason about what can occur and when. A historical example that always grated against my sensibilities was

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic