[PATCH] D37762: [InstCombine] Remove single use restriction from InstCombine's explicit sinking code.

Hal Finkel via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 13 14:12:00 PDT 2017


hfinkel added a comment.

In https://reviews.llvm.org/D37762#869696, @craig.topper wrote:

> Here's a longer version of what I saw in the benchmark i was looking at
>
> y1 = 0;
>  y2 = (x & 2) ? (y1 | C1) : y1
>  y3 = (x & 4) ? (y2 | C2) : y2
>  y4 = (x & 8) ? (y3 | C3) : y3
>  y5 = (x & 16) ? (y4 | C4) : y4
>  y6 = (x & 32) ? (y5 | C5) : y5
>  y7 = (x & 64) ? (y6 | C6) : y6
>  if (x & 254) {
>
>   y8 = (x & 128) ? (y7 | C7) : y7
>   store y8 to memory
>
> }
>
> As you can see y7 is only used inside the if body, but we didn’t sink it. The select for y8, the (y7 | C7) for its left hand size and the (x & 128) all started output above the if (x & 254) and were pushed down because they were only needed by the store.
>
> Is there some other pass that I should expect to sink this code so that we don't waste time decoding/executing the resulting ors and cmovs when (x & 254) is false?


Interesting. Nothing occurs to me (at the IR level - we do have MachineSink in CodeGen). Should we do this in CGP, or is there a reason to do it earlier?

I may have said this before, but we should figure out what we want our canonical form to be. Execute things as early as possible (i.e., aggressive hoisting), but as few times as possible (i.e., still sink out of loops), is one possibility. Lacking other motivations, that's what I'd recommend.


https://reviews.llvm.org/D37762





More information about the llvm-commits mailing list