Juneyoung Lee a66bc1c4a3 [DAGCombiner] Avoid converting (x or/xor const) + y to (x + y) + const if benefit is unclear
This patch resolves suboptimal code generation reported by https://github.com/llvm/llvm-project/issues/60571 .

DAGCombiner currently converts `(x or/xor const) + y` to `(x + y) + const` if this is valid.
However, if `.. + const` is broken down into a sequences of adds with carries, the benefit is not clear, introducing two more add(-with-carry) ops (total 6) in the case of the reported issue whereas the optimal sequence must only have 4 add(-with-carry)s.

This patch resolves this issue by allowing this conversion only when (1) `.. + const` is legal or promotable, or (2) `const` is a sign bit because it does not introduce more adds.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D144116
2023-03-08 18:13:57 +00:00
..
2023-03-01 16:22:13 +00:00
2022-06-07 18:57:59 +01:00
2023-01-03 15:09:29 +00:00
2023-01-24 22:36:39 +01:00
2022-07-25 09:08:10 +01:00
2022-08-24 22:41:38 +00:00
2022-08-24 22:41:38 +00:00
2023-01-24 22:36:39 +01:00
2022-08-24 11:09:22 +00:00
2023-02-22 09:17:25 +00: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.