Add a number of helper functions to match scalar or vector equivalent constant/splat values to allow most of the combine patterns to be used by vectors.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
829 ↗ | (On Diff #73961) | What if we have a BUILD_VECTOR of constants where one of the constants going into it is opaque? |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
829 ↗ | (On Diff #73961) | I see what you're saying. For the current cases it won't have much effect - some of the combines would switch ops around but the expected constant folding will just fail. I'll change isNonOpaqueConstantOrConstantVector to check for opaques in the build vector, and make a separate isConstantOrConstantVector helper as well which we can use in a couple of places. Thorough tests of opaque vector elements might be tricky though. |
Updated isNonOpaqueConstantOrConstantVector to isNonOpaqueConstantOrNonOpaqueConstantVector to check that no vector elements are opaque constants. Also added isConstantOrConstantVector helper that doesn't care about opaque. Both of these allow undef vector elements.
Updated the helpers to not allow implicit truncation in build vectors - this will be necessary for the reuse of these helpers in other combines (e.g. SUB and MUL). This isn't necessary for the isNullConstantOrNullSplatConstant case.
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
859 ↗ | (On Diff #74050) | Maybe merge isConstantOrConstantVector and isNonOpaqueConstantOrNonOpaqueConstantVector and have a nonOpaque parameter? |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
859 ↗ | (On Diff #74050) | Will do - it'll help reduce the length of those function names! |
Added NoOpaques optional argument to isConstantOrConstantVector and removed isNonOpaqueConstantOrNonOpaqueConstantVector helper
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
832 ↗ | (On Diff #74166) | "return !(NoOpaques && Const->isOpaque())" ? |
LGTM
Although I'm curious - do you see this in real code?
To the best of my understanding, the major goal of DAG-level constant folding is to get rid of constants that weren't visible on the IR level. This happens with scalars quite a lot (e.g. because of GEP lowering), but I'm not sure I understand where "new" vector constants come from.
Thanks Michael, the only pattern from visitADD I've seen in the wild is "(a+b) -> (a|b)", but this will hopefully be the first stage in making most of the DAGCombiner combines properly support vector patterns when they do. Both visitSUB and visitAND/visitOR/visitXOR have a lot more cases that do occur but I wanted to start with a relatively easy one! These along with better vector support for computeKnownBits (et al.) should have a greater (accumulative) effect on vector IR.
Hi @RKSimon
I know this CR is quite old, I am trying to remove the "not allow implicit truncation" restriction for one optimization. I am somewhat new to this part of the compiler, can you please explain to me why this is necessary for SUB and MUL combines. An example would be great. Thanks !
I can't remember tbh - best way to find out would be for you to remove the restriction and run check-llvm-codegen to see what changes/regresses/asserts/explodes....