Open XChy opened 7 months ago
Does this produce better optimizations in the surrounding context? I'm not sure this transform is worthwhile.
Does this produce better optimizations in the surrounding context? I'm not sure this transform is worthwhile.
No, just as this example shows. I don't insist on it since it doesn't bring better codegen..
Detected a similar but more complex pattern just now: https://alive2.llvm.org/ce/z/pTzsqM This one produces better optimizations in the surrounding context, see also: https://godbolt.org/z/9d5n7o1er
Does this produce better optimizations in the surrounding context? I'm not sure this transform is worthwhile.
On RISCV, it will allow to use the smax instruction even for the original simplified example instead of the more complex code.
Does this produce better optimizations in the surrounding context? I'm not sure this transform is worthwhile.
On RISCV, it will allow to use the smax instruction even for the original simplified example instead of the more complex code.
It depends on the materialization cost for the immediates.
Detect better optimization in the surrounding context, mainly when the select is used multiple times. An example: https://alive2.llvm.org/ce/z/7Hb43S , which eliminates an add instruction.
I believe https://github.com/rust-lang/rust/issues/123845 is another motivating case for this. That one is smin with multi-use condition and one-use add.
Alive2 proof: https://alive2.llvm.org/ce/z/ERjNs4
Motivating example
can be folded to:
LLVM does well when
C1
orC2
is not constant, but when both are constants, LLVM missed it. Though this example doesn't show better codegen, I think it's a better canonicalization.Real-world motivation
This snippet of IR is derived from protobuf/generated_message_tctable_lite.cc after O3 pipeline (original IR is from llvm-opt-benchmark). Original IR is too big to attach here, email me to get it please.
Let me know if you can confirm that it's an optimization opportunity, thanks.