[PATCH] D82730: [SimplifyCFG] Merge identical basic blocks (WIP)

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 30 09:47:23 PDT 2020


nikic added a comment.

In D82730#2120593 <https://reviews.llvm.org/D82730#2120593>, @fhahn wrote:

> I think @AndrewLitteken & @paquette are working on adding infrastructure for IR outlining. Might be worth syncing up on sharing the IR equivalence checks/hashing. It would be good to have a single place where we define those kinds of IR equivalence for merging/outlining, rather than having multiple slightly diverging ones.
>
> Also, I am not sure if SimplifyCFG is the ideal place to do this transform, as it runs quite a few times in the pipeline. I think running the merging sometime after GVN should allow us to catch most cases.


For reference, these are the current compile-time numbers: http://llvm-compile-time-tracker.com/compare.php?from=ef79026aad943fa9b5c12d462127cd9dfa9ea0d8&to=8fb2407c2f795d92f2e5d69a483ab749eff488f2&stat=instructions

After fixing some obvious issues, the merging itself appears to be quite cheap. The big compile-time effect (in either direction) is because this changes the amount of IR (text-size changes <http://llvm-compile-time-tracker.com/compare.php?from=ef79026aad943fa9b5c12d462127cd9dfa9ea0d8&to=8fb2407c2f795d92f2e5d69a483ab749eff488f2&stat=size-text>) and has impact on following optimizations (the largest regression is addressed by D82799 <https://reviews.llvm.org/D82799>).

That said, the particular placement here is just an initial attempt that puts it next to the existing merging code for return blocks, it may not be the best placement. Having it as a separate pass, or in a different position in SimplifyCFG may make more sense.

Performing merging after GVN seems too late. The block merging is intended not just as a code-size optimization, but also as a means to enable further control-flow optimization. As such, it should probably at least happen before jump threading.

> Also, various parts in the backend do not handle huge BBs well (in terms of compile time), so we should probably avoid creating BBs that are too large.

I'm not immediately seeing how this optimization would result in larger blocks?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82730/new/

https://reviews.llvm.org/D82730





More information about the llvm-commits mailing list