This patch uses visitMUL to combine VP_MUL, shares most logic of MUL with VP_MUL.
I believe so. Also for vp ops other than select or merge, if the mask is undef, we can scratch the operation entirely. If evl is undef, we can cut short to unreachable.
I think we should only use getSplatVector for scalable vectors. Fixed vectors should use getSplatBuildVector.
You can just call DAG.getConstant(0, SDLoc(N), VT); It will do the right thing.
DAG.getConstant(0, SDLoc(N), VT)
Same comment as above.
@jacquesguan Thanks for working on VP optimizations! We just discussed on the VP syncup call where we want to go with this.
The thing is that this patch is essentially replicating the existing MUL DAGCombiner patterns for VP_MUL. Ideally, we would lift the existing DAGCombiner logic to work on both VP and non-VP SDNodes - automatically.
I've implemented something like this in NEC's open source LLVM stack:
The idea is to templatize the pattern-matching and rewriting code and instantiate that for each VP and non-VP. In essence, https://reviews.llvm.org/D92086 but on the SelectionDAG.
Would you be interested in working on a more general approach? Please contact me directly so we can get you on the VP Discord server or arrange a call to talk about this.
I'm concerned about the number of checks for IsVP. It looks like maybe this function will be hard to maintain in the future. Every new change will have to think about whether it works for VP. Most LLVM developers don't care about VP so may miss this detail.
Yes, it is a problem, and even we remove all IsVP in the function, a developper that wants to change this function should also think about whether the change works on VP version too. Actually I used a new function visitVP_MUL to implement the combination of VP_MUL at begining, and @simoll suggested to make the existed logic work on both no-vp and vp ops, so I switch to this way. Do you think which one is a better solution, reuse the visitMUL or create a new visitVP_MUL with some repeat code?