| Issue |
178616
|
| Summary |
[GVN][PRE][RISCV] Worse code generation for a `std::min_element` case
|
| Labels |
backend:RISC-V,
missed-optimization,
llvm:GVN
|
| Assignees |
|
| Reporter |
wangpc-pp
|
We found a real-world `std::min_element` case that is worse than GCC: https://godbolt.org/z/bhn1WvE6a
There are 2 issues:
1. The sub-optimal `Zicond` sequences, which should be fixed by #80124.
2. LLVM generates two `flw`s in the loop while GCC has only one. The LLVM's total instructions in the loop is almost 50% larger than GCC's. This is because GCC hoists the first `flw` to the preheader. I checked the GCC's log and this optimization is done by `pre` in [`gcc/tree-ssa-pre.cc`](https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-ssa-pre.cc).
For 2, it is a common issue in LLVM because AArch64 and other targets have the same problem: https://godbolt.org/z/EPTnsMn4G
There are several parts that may be related to the second issue:
1. GVN/PRE. The LLVM seems not to know how to PRE loads with indirection?
2. MemorySSA. I suspected it at the first time, but I just found that the current `GVN` implementation doesn't actually use `MemorySSA`. It is still using `MemoryDependenceAnalysis`, and it regresses in this case if we enable the `MemorySSA` via `-mllvm -enable-gvn-memoryssa -mllvm -enable-gvn-memdep=false`. It seems that the `MemorySSA` is not fully integrated into GVN now.
3. IndVarSimplify. These instructions that are not hoisted look like induction variables so we may be able to simplify them?
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
