This is an archive of the discontinued LLVM Phabricator instance.

[DAGCombiner][VP] Add DAGCombine for VP_MUL.
Needs ReviewPublic

Authored by jacquesguan on Mar 8 2022, 12:06 AM.

Details

Summary

This patch uses visitMUL to combine VP_MUL, shares most logic of MUL with VP_MUL.

Diff Detail

Event Timeline

jacquesguan created this revision.Mar 8 2022, 12:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 8 2022, 12:06 AM
jacquesguan requested review of this revision.Mar 8 2022, 12:06 AM
RKSimon added inline comments.Mar 8 2022, 9:06 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25687

(style) Don't use auto unless the type is obvious (i.e. a cast<>)

craig.topper added inline comments.Mar 8 2022, 9:21 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25687

Don't call isConstOrConstSplat(N1) twice

25689

What about mul by positive 1 or 0?

Address comment.

llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25687

Done.

25689

Done.

craig.topper added inline comments.Mar 9 2022, 11:53 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25690

If one of the true/false values of the VP_SELECT is undef can we ignore the mask and EVL and return the other operand? @simoll @frasercrmck

simoll added inline comments.Mar 11 2022, 8:15 AM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25690

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.

Address comment.

jacquesguan added inline comments.Mar 13 2022, 7:24 PM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25690

Done, thanks.

craig.topper added inline comments.Mar 13 2022, 7:44 PM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25692

I think we should only use getSplatVector for scalable vectors. Fixed vectors should use getSplatBuildVector.

25692

You can just call DAG.getConstant(0, SDLoc(N), VT); It will do the right thing.

25703

DAG.getConstant(0, SDLoc(N), VT)

25711

Same comment as above.

Address comment.

jacquesguan added inline comments.Mar 13 2022, 8:45 PM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
25692

Done.

25703

Done.

25711

Done.

@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:
https://github.com/sx-aurora-dev/llvm-project/blob/develop/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp

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.

reuse visitMUL to combine VP_MUL.

jacquesguan edited the summary of this revision. (Show Details)Jun 8 2023, 7:47 PM
jacquesguan added a reviewer: fakepaper56.

fix comment.

craig.topper added inline comments.Jun 8 2023, 9:46 PM
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
4274

IS -> Is

4282

What does it mean to support a VP op in FoldConstantArithmetic?

Address comment.

jacquesguan marked 2 inline comments as done.Jun 9 2023, 12:15 AM
jacquesguan added inline comments.
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
4282

I was thinking wrong. This TODO is removed now.

jacquesguan marked an inline comment as done.Jun 24 2023, 11:29 PM

ping.

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.

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?