Two equal instrs are partially redundant if their basic blocks are reachable
from one to another but one doesn't dominate another. For this case
one can hoist them to their common dominator block. But such hoisting makes
optimization sense only if their blocks are reachable from one to another
without passing through their common dominator. This change makes this check
preventing PRE from useless instr duplication (leading to hoisting after CSE
elimination).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 34092 Build 34091: arc lint + arc unit
Event Timeline
llvm/lib/CodeGen/MachineCSE.cpp | ||
---|---|---|
824 | Unrelated with this patch: Check CMBB != nullptr? |
llvm/lib/CodeGen/MachineCSE.cpp | ||
---|---|---|
824 | Good point, I haven't faced this issue, but this is actually potentially a bug. I'm to include fix right to this patch. Thank you! |
Just to make sure I understand the change correctly:
This can still hoist instructions outside of their BB and execute them speculatively even if you can't prove that all possible paths execute the instruction, am I right?
Hi @aymanmus, yes, you are right, and this fact is confusing me. You are right -- the speculativeinstruction execution shouldn't be possible after optimization, even if the average performance is growing up. This wasn't intented when I implemented PRE, I'm to take actions for fixing this.
Sure. I'm to take one-two days more for fixing effort, otherwise I will have to revert my original commit.
Hi all! I've figured out that my current implementation of PRE is incorrect and it needs to be either corrected, restricted or reverted.
The issue is that current PRE can actually hoist instruction executing it speculatively for some CFG paths which potentially leads to perf degradation. However I believe that current heuristic PRE is rather useful if it is restricted enough. Good restriction (apart from this revision) is implemented by @lkail here: https://reviews.llvm.org/D64394, it is based on basic block frequencies comparision.
@asbirlea, @aymanmus, @igorb -- does this restriction solve your particular issues with perf degradation?
Yes, this restriction still allows speculative execution (so one need to forbid hoisting of "illegal" instructions like throwable ones), but this execution consider to be beneficial.
Unrelated with this patch: Check CMBB != nullptr?