[llvm] r297839 - Refactor SimplifyCFG:canSinkInstructions [NFC]
Eric Liu via llvm-commits
llvm-commits at lists.llvm.org
Thu Mar 16 01:37:54 PDT 2017
Hi Aditya,
Sorry that I forgot to attach more details. The test was failing on x86-64
in Release mode with this revision. Please let me know if you need more
information.
This is the output:
[38/38] Running the LLVM regression tests
FAIL: LLVM :: Transforms/SimplifyCFG/sink-common-code.ll (19093 of 20040)
******************** TEST 'LLVM ::
Transforms/SimplifyCFG/sink-common-code.ll' FAILED ********************
Script:
--
/usr/local/google/home/ioeric/llvm-build/./bin/opt <
/usr/local/google/home/ioeric/llvm/test/Transforms/SimplifyCFG/sink-common-code.ll
-simplifycfg -S | /usr/local/google/home/ioeric/llvm-build/./bin/FileCheck
/usr/local/google/home/ioeric/llvm/test/Transforms/SimplifyCFG/sink-common-code.ll
--
Exit Code: 1
Command Output (stderr):
--
<stdin>:214:9: error: CHECK-NOT: string occurred!
%sv2 = load i32, i32* %gepb
^
/usr/local/google/home/ioeric/llvm/test/Transforms/SimplifyCFG/sink-common-code.ll:410:14:
note: CHECK-NOT: pattern specified here
; CHECK-NOT: load
^
<stdin>:242:9: error: CHECK-NOT: string occurred!
%sv2 = load i32, i32* %gepb
^
/usr/local/google/home/ioeric/llvm/test/Transforms/SimplifyCFG/sink-common-code.ll:441:14:
note: CHECK-NOT: pattern specified here
; CHECK-NOT: load
^
--
********************
Testing Time: 30.37s
********************
Failing Tests (1):
LLVM :: Transforms/SimplifyCFG/sink-common-code.ll
Expected Passes : 19420
Expected Failures : 143
Unsupported Tests : 476
Unexpected Failures: 1
On Wed, Mar 15, 2017 at 10:34 PM Aditya K <hiraditya at msn.com> wrote:
>
> Hi Eric,
> I pushed the patch because I did not see this error on x86-64. Are you
> seeing this on a different target.
>
> Thanks,
> -Aditya
>
> ------------------------------
> *From:* Eric Liu <ioeric at google.com>
> *Sent:* Wednesday, March 15, 2017 9:42 AM
> *To:* Aditya Kumar; llvm-commits at lists.llvm.org
> *Subject:* Re: [llvm] r297839 - Refactor SimplifyCFG:canSinkInstructions
> [NFC]
>
> Hi Aditya, this commit breaks Transforms/SimplifyCFG/sink-common-code.ll.
>
> I've reverted it with r297845 :(
>
> - Eric
>
> On Wed, Mar 15, 2017 at 3:38 PM Aditya Kumar via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> Author: hiraditya
> Date: Wed Mar 15 09:26:45 2017
> New Revision: 297839
>
> URL: http://llvm.org/viewvc/llvm-project?rev=297839&view=rev
> Log:
> Refactor SimplifyCFG:canSinkInstructions [NFC]
>
> Modified:
> llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp
>
> Modified: llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp?rev=297839&r1=297838&r2=297839&view=diff
>
> ==============================================================================
> --- llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp (original)
> +++ llvm/trunk/lib/Transforms/Utils/SimplifyCFG.cpp Wed Mar 15 09:26:45
> 2017
> @@ -1463,39 +1463,39 @@ static bool canSinkInstructions(
> if (!isa<StoreInst>(I0)) {
> auto *PNUse = dyn_cast<PHINode>(*I0->user_begin());
> auto *Succ = I0->getParent()->getTerminator()->getSuccessor(0);
> - if (!all_of(Insts, [&PNUse,&Succ](const Instruction *I) -> bool {
> + if (!PNUse || PNUse->getParent() != Succ)
> + return false;
> + if (!all_of(Insts, [&PNUse](const Instruction *I) -> bool {
> auto *U = cast<Instruction>(*I->user_begin());
> - return (PNUse &&
> - PNUse->getParent() == Succ &&
> - PNUse->getIncomingValueForBlock(I->getParent()) == I) ||
> - U->getParent() == I->getParent();
> + return (PNUse->getIncomingValueForBlock(I->getParent()) == I) ||
> + U->getParent() == I->getParent();
> }))
> return false;
> }
>
> + // Because SROA can't handle speculating stores of selects, try not
> + // to sink loads or stores of allocas when we'd have to create a PHI for
> + // the address operand. Also, because it is likely that loads or stores
> + // of allocas will disappear when Mem2Reg/SROA is run, don't sink them.
> + // This can cause code churn which can have unintended consequences down
> + // the line - see https://llvm.org/bugs/show_bug.cgi?id=30244.
> + // FIXME: This is a workaround for a deficiency in SROA - see
> + // https://llvm.org/bugs/show_bug.cgi?id=30188
> + if (isa<StoreInst>(I0) &&
> + any_of(Insts, [](const Instruction *I) {
> + return isa<AllocaInst>(I->getOperand(1));
> + }))
> + return false;
> + if (isa<LoadInst>(I0) && any_of(Insts, [](const Instruction *I) {
> + return isa<AllocaInst>(I->getOperand(0));
> + }))
> + return false;
> +
> for (unsigned OI = 0, OE = I0->getNumOperands(); OI != OE; ++OI) {
> if (I0->getOperand(OI)->getType()->isTokenTy())
> // Don't touch any operand of token type.
> return false;
>
> - // Because SROA can't handle speculating stores of selects, try not
> - // to sink loads or stores of allocas when we'd have to create a PHI
> for
> - // the address operand. Also, because it is likely that loads or
> stores
> - // of allocas will disappear when Mem2Reg/SROA is run, don't sink
> them.
> - // This can cause code churn which can have unintended consequences
> down
> - // the line - see https://llvm.org/bugs/show_bug.cgi?id=30244.
> - // FIXME: This is a workaround for a deficiency in SROA - see
> - // https://llvm.org/bugs/show_bug.cgi?id=30188
> - if (OI == 1 && isa<StoreInst>(I0) &&
> - any_of(Insts, [](const Instruction *I) {
> - return isa<AllocaInst>(I->getOperand(1));
> - }))
> - return false;
> - if (OI == 0 && isa<LoadInst>(I0) && any_of(Insts, [](const
> Instruction *I) {
> - return isa<AllocaInst>(I->getOperand(0));
> - }))
> - return false;
> -
> auto SameAsI0 = [&I0, OI](const Instruction *I) {
> assert(I->getNumOperands() == I0->getNumOperands());
> return I->getOperand(OI) == I0->getOperand(OI);
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170316/7bcb631f/attachment.html>
More information about the llvm-commits
mailing list