[llvm-dev] Optimizing jumps to identical code blocks
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 1 15:06:59 PDT 2015
This looks like at least one missing case in SimplifyCFG most likely. I
suspect that our tail commoning code is being restricted to two incoming
blocks to a phi, but that's just a guess. Can you file a bug with the
IR from your gist attached?
On 09/30/2015 02:42 AM, Andrea Canciani via llvm-dev wrote:
> Rust pattern matching code can sometimes generate very redundant LLVM
> IR, in which several branches contain exactly the same code.
> LLVM successfully unifies that, but the dispatching mechanism does not
> simplify accordingly.
> I created a gist here:
> (based on two examples available in Rust issues:
> https://github.com/rust-lang/rust/issues/13623#issuecomment-136700526 )
> In "enum4.s"
> cmpl $1, %eax
> je LBB0_5
> cmpl $2, %eax
> je LBB0_5
> cmpl $3, %eax
> could be removed.
> (Further optimization would be possible by observing that the two
> 32-bit comparison could be unified into a single 64-bit comparison,
> but I believe this is a different issue)
> In "enum6.s" all of the elements of the jump table point to the same
> label (which is also right after the jump to the table dispatch code),
> so the jump table is actually useless.
> Is there any combination of passes that should make it possible for
> LLVM to optimize this?
> Would outline + merge functions be a step in the right direction?
> I googled for a similar thread in the mailing list and I found
> Unfortunately the thread does not provide a way to remove identical
> blocks in LLVM IR. Instead it suggests that this is only possible by
> relying on target-dependent optimizations. Does this mean that the
> best approach would be to make the target-dependent passes also
> optimize away jumps (when possible)?
> I am somewhat afraid that this would prevent further optimizations
> that might be exposed by the removal of identical blocks (like the
> 32+32 -> 64 coalescing I mentioned before).
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev