[PATCH] D134023: [InstCombine] Try to sink instructions into nearest common dominator of its users

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 16 02:04:02 PDT 2022


nikic requested changes to this revision.
nikic added a comment.
This revision now requires changes to proceed.

This has non-trivial compile-time impact: http://llvm-compile-time-tracker.com/compare.php?from=57c7bb3ec89565c68f858d316504668f9d214d59&to=aaee8dd0c8e1da698e87d7a62b23b4c3526a4a14&stat=instructions

The sinking functionality in InstCombine has always been something of a hack in that it is largely orthogonal to InstCombine's core purpose. It is only acceptable as long as it is reasonably cheap. If you want support for something that goes beyond "trivial" sinking, then that must go into a dedicated sinking pass (which does not have to suffer from other InstCombine sinking limitations either).

We may be able to consider this if the implementation can be changed to be essentially free. The used implementation approach is fairly weird in that InstCombine will only sink into a direct successor of the block (ignoring terminator blocks for now). So this spends effort computing an NCD and will then only sink into it if it happens to be a successor of BB with a unique predecessor. However, the fact that it is an NCD is not actually relevant, we can sink into any dominating block. So a possible alternative approach is to find out a) whether there is any unique predecessor successor of BB that dominates the first use and b) that successor also dominates all the other uses. I don't know if that will help, but it might (it will also allow sinking in more cases.)


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

https://reviews.llvm.org/D134023



More information about the llvm-commits mailing list