[PATCH] D111806: [LICM] Check the number of divergent paths from loop header to target block

Philip Reames via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 22 16:26:54 PST 2021


reames added a comment.

In D111806#3079379 <https://reviews.llvm.org/D111806#3079379>, @modimo wrote:

> To keep the conversation coherent I'll talk about the same feedback for D87551 <https://reviews.llvm.org/D87551> here:
>
> In D111806#3067256 <https://reviews.llvm.org/D111806#3067256>, @reames wrote:
>
>> If we were being presented with hard cases to undo with a cost based transform, I might be willing to entertain the notion that LICM should be non-canonical.  As it stands, I don't see such examples.
>
> The original change that prompted adding this from @wenlei is a more complicated situation https://reviews.llvm.org/D65060#1596899. Specifically, once the values are hoisted out of the 200 switch arms there's not longer a dominating use block to sink them back into. In addition, the block frequency information at that point no longer indicates that there's an issue from the hoisting. Getting MachineLICM to handle that case is complicated and I suspect fragile.

FYI, I find this very unconvincing.  First, the motivating test case appears to have been discussed, but never shared.  Second, as discussed, we appeared to have something along the lines of a switch mapping to address offsets, which is then loaded from.  We can and do pull such geps down through the phi, and that optimization should probably have triggered on the discussed example.  In general, a missing optimization is a *bad* motivation for disabling a canonicalization.


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

https://reviews.llvm.org/D111806



More information about the llvm-commits mailing list