[PATCH] D140647: Handle simple diamond CFG hoisting in DivRemPairs.
Owen Anderson via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Dec 24 14:31:20 PST 2022
resistor added a comment.
In D140647#4016111 <https://reviews.llvm.org/D140647#4016111>, @lebedev.ri wrote:
> I'm guessing what other reviewers are trying to say,
> is that we might be missing something to to effect of:
>
> if(DivBB != PredBB && RemBB != PredBB && !HasDivRemOp)
> continue; // Don't hoist both into predecessor if we don't have divrem instruction.
>
> But it's not obvious to me if that it's actually worse,
> because instruction counting is not really the right way
> to gauge code performance.
>
> Div/Rem is usually *really* that bad. We move really really
> costly instruction from both branches to their predecessor
>
> 1. if branch is mispredicted, we won't have to recompute it
> 2. if the inputs are already avaliable, it can start executing earlier than it would have in the branches, thus we hide some of it's latency
> 3. in turn, instructions that depend on results of those instructions may get results earlier, and start executing earlier
Continuing with Sergei's example, the transformation *is* profitable from a code size and latency perspective on x86: https://godbolt.org/z/xo7P1MnGr
It seems like the simplest path forward here is to conditionalize the transformation as you suggest. I will look into this.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D140647/new/
https://reviews.llvm.org/D140647
More information about the llvm-commits
mailing list