woruyu bbcebec3af
[DAG] Refactor X86 combineVSelectWithAllOnesOrZeros fold into a generic DAG Combine (#145298)
This PR resolves https://github.com/llvm/llvm-project/issues/144513

The modification include five pattern :
1.vselect Cond, 0, 0 → 0
2.vselect Cond, -1, 0 → bitcast Cond
3.vselect Cond, -1, x → or Cond, x
4.vselect Cond, x, 0 → and Cond, x
5.vselect Cond, 000..., X -> andn Cond, X

1-4 have been migrated to DAGCombine. 5 still in x86 code.

The reason is that you cannot use the andn instruction directly in
DAGCombine, you can only use and+xor, which will introduce optimization
order issues. For example, in the x86 backend, select Cond, 0, x →
(~Cond) & x, the backend will first check whether the cond node of
(~Cond) is a setcc node. If so, it will modify the comparison operator
of the condition.So the x86 backend cannot complete the optimization of
andn.In short, I think it is a better choice to keep the pattern of
vselect Cond, 000..., X instead of and+xor in combineDAG.

For commit, the first is code changes and x86 test(note 1), the second
is tests in other backend(node 2).

---------

Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk>
2025-07-02 15:07:48 +01:00
..
2025-03-30 16:38:16 -07:00

++ SVE CodeGen Warnings ++

When the WARN check lines fail in the SVE codegen tests it most likely means you
have introduced a warning due to:
1. Adding an invalid call to VectorType::getNumElements() or EVT::getVectorNumElements()
   when the type is a scalable vector.
2. Relying upon an implicit cast conversion from TypeSize to uint64_t.

For generic code, please modify your code to work with ElementCount and TypeSize directly.
For target-specific code that only deals with fixed-width vectors, use the fixed-size interfaces.
Please refer to the code where those functions live for more details.