[PATCH] D105309: [InstCombine] Don't combine PHI before catchswitch
Reid Kleckner via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 1 13:14:28 PDT 2021
rnk added inline comments.
================
Comment at: llvm/lib/Transforms/InstCombine/InstCombinePHI.cpp:1331
CheckedIVs.insert(IV0);
if (IV0 != IV0Stripped &&
all_of(PN.incoming_values(), [&CheckedIVs, IV0Stripped](Value *IV) {
----------------
Every other return path of `InstCombinerImpl::visitPHINode` appears to create and return an existing instruction of a new phi node. This one is special in that it creates a new non-phi instruction.
The insertion location is not determined here, but it is predictable, it's the first available insertion point after the phi, but the phi's block has no insertion point. The generic way to test for this is to compare `getInsertionPoint` against the end iterator.
So, all the other transforms seem fine. It's reasonable to put a more targeted fix right here:
&& PN.getParent()->getFirstNonPHI() != PN.getParent()->end()
================
Comment at: llvm/test/Transforms/InstCombine/catchswitch-phi.ll:1
+target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128-ni:1"
+target triple = "wasm32-unknown-unknown"
----------------
lebedev.ri wrote:
> This isn't testing anything
That's true, and I don't see any cast instructions to trigger the codepath we are looking at.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105309/new/
https://reviews.llvm.org/D105309
More information about the llvm-commits
mailing list