[llvm] r314435 - [JumpThreading] Preserve DT and LVI across the pass

Wed Oct 4 09:47:52 PDT 2017

> On Oct 4, 2017, at 9:25 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 
> +jakub for real.
> 
> On Wed, Oct 4, 2017 at 9:21 AM, Daniel Berlin <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> wrote:
> +jakub
> 
> I don't think preservation should be controlled by a flag.  That seems like not a great path forward.
> Either we should make it fast enough, or we should give up :)
> 
> Do you have any profiles on this?
I don’t, but it seems pretty clear what’s going on there - we do an extra work (preserving DT) for no benefits (we’re recomputing it a couple of passes later anyway). The pass after which it’s recomputed is SimplifyCFG, and I think it would be a much bigger endeavor to teach it to account for DT - so putting it under a flag for JumpThreading could help doing this work incrementally.

Michael

> 
> 
> 
> On Sat, Sep 30, 2017 at 12:19 PM, Michael Zolotukhin via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
> For the record, we also detected significant compile-time increases caused by this patch. It caused up to 10% slow downs on sqlite3 and some other tests from CTMark/LLVM testsuite (on O3/LTO and other optsets).
> 
> Reproducer:
> 
> time clang-r314435/bin/clang  -DNDEBUG -O3 -arch arm64 -isysroot $SYSROOT -DSTDC_HEADERS=1  -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_THREADSAFE=0  -w -o sqlite3.c.o -c $TESTSUITE/CTMark/sqlite3/sqlite3.c
> real    0m20.235s
> user    0m20.130s
> sys     0m0.091s
> 
> time clang-r314432/bin/clang  -DNDEBUG -O3 -arch arm64 -isysroot $SYSROOT -DSTDC_HEADERS=1  -DSQLITE_OMIT_LOAD_EXTENSION=1 -DSQLITE_THREADSAFE=0  -w -o sqlite3.c.o -c $TESTSUITE/CTMark/sqlite3/sqlite3.c
> real    0m19.254s
> user    0m19.154s
> sys     0m0.094s
> 
> JumpThreading started to consume much longer time trying to preserve DT, but DT was still being recomputed couple of passes later. In general, I agree that we should preserve DT and in the end it should be beneficial for compile time too, but can we put it under a flag for now until we can actually benefit from it?
> 
> Thanks,
> Michael
> 
> 
>> On Sep 30, 2017, at 5:02 AM, Daniel Jasper via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> 
>> I found other places where this Clang was running into this segfault. Reverted for now in r314589.
>> 
>> On Fri, Sep 29, 2017 at 10:19 PM, Friedman, Eli via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> On 9/28/2017 10:24 AM, Evandro Menezes via llvm-commits wrote:
>>> Author: evandro
>>> Date: Thu Sep 28 10:24:40 2017
>>> New Revision: 314435
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=314435&view=rev <http://llvm.org/viewvc/llvm-project?rev=314435&view=rev>
>>> Log:
>>> [JumpThreading] Preserve DT and LVI across the pass
>>> 
>>> JumpThreading now preserves dominance and lazy value information across the
>>> entire pass.  The pass manager is also informed of this preservation with
>>> the goal of DT and LVI being recalculated fewer times overall during
>>> compilation.
>>> 
>>> This change prepares JumpThreading for enhanced opportunities; particularly
>>> those across loop boundaries.
>>> 
>>> Patch by: Brian Rzycki <b.rzycki at samsung.com> <mailto:b.rzycki at samsung.com>,
>>>           Sebastian Pop <s.pop at samsung.com> <mailto:s.pop at samsung.com>
>>> 
>>> Differential revision: https://reviews.llvm.org/D37528 <https://reviews.llvm.org/D37528>
>> 
>> It looks like this is causing an assertion failure on the polly aosp buildbot (http://lab.llvm.org:8011/builders/aosp-O3-polly-before-vectorizer-unprofitable/builds/266/steps/build-aosp/logs/stdio <http://lab.llvm.org:8011/builders/aosp-O3-polly-before-vectorizer-unprofitable/builds/266/steps/build-aosp/logs/stdio>):
>> clang: /var/lib/buildbot/slaves/hexagon-build-03/aosp/llvm.src/include/llvm/Support/GenericDomTreeConstruction.h:906: static void llvm::DomTreeBuilder::SemiNCAInfo<llvm::DominatorTreeBase<llvm::BasicBlock, false> >::DeleteEdge(DomTreeT &, const BatchUpdatePtr, const NodePtr, const NodePtr) [DomTreeT = llvm::DominatorTreeBase<llvm::BasicBlock, false>]: Assertion `!IsSuccessor(To, From) && "Deleted edge still exists in the CFG!"' failed.
>> #0 0x00000000014f6fc4 PrintStackTraceSignalHandler(void*) (llvm.inst/bin/clang+0x14f6fc4)
>> #1 0x00000000014f72d6 SignalHandler(int) (llvm.inst/bin/clang+0x14f72d6)
>> #2 0x00007f694afddd10 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10d10)
>> #3 0x00007f6949bbb267 gsignal /build/buildd/glibc-2.21/signal/../sysdeps/unix/sysv/linux/raise.c:55:0
>> #4 0x00007f6949bbceca abort /build/buildd/glibc-2.21/stdlib/abort.c:91:0
>> #5 0x00007f6949bb403d __assert_fail_base /build/buildd/glibc-2.21/assert/assert.c:92:0
>> #6 0x00007f6949bb40f2 (/lib/x86_64-linux-gnu/libc.so.6+0x2e0f2)
>> #7 0x000000000104a1dc (llvm.inst/bin/clang+0x104a1dc)
>> #8 0x0000000001357fd9 llvm::JumpThreadingPass::ProcessBlock(llvm::BasicBlock*) (llvm.inst/bin/clang+0x1357fd9)
>> #9 0x0000000001356e6e llvm::JumpThreadingPass::runImpl(llvm::Function&, llvm::TargetLibraryInfo*, llvm::LazyValueInfo*, llvm::AAResults*, llvm::DominatorTree*, bool, std::unique_ptr<llvm::BlockFrequencyInfo, std::default_delete<llvm::BlockFrequencyInfo> >, std::unique_ptr<llvm::BranchProbabilityInfo, std::default_delete<llvm::BranchProbabilityInfo> >) (llvm.inst/bin/clang+0x1356e6e)
>> #10 0x0000000001363c49 (anonymous namespace)::JumpThreading::runOnFunction(llvm::Function&) (llvm.inst/bin/clang+0x1363c49)
>> #11 0x00000000010a53c4 llvm::FPPassManager::runOnFunction(llvm::Function&) (llvm.inst/bin/clang+0x10a53c4)
>> #12 0x00000000031f7376 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (llvm.inst/bin/clang+0x31f7376)
>> #13 0x00000000010a5b05 llvm::legacy::PassManagerImpl::run(llvm::Module&) (llvm.inst/bin/clang+0x10a5b05)
>> #14 0x0000000001688beb clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (llvm.inst/bin/clang+0x1688beb)
>> #15 0x0000000001ed7672 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (llvm.inst/bin/clang+0x1ed7672)
>> #16 0x0000000002195235 clang::ParseAST(clang::Sema&, bool, bool) (llvm.inst/bin/clang+0x2195235)
>> #17 0x0000000001a75628 clang::FrontendAction::Execute() (llvm.inst/bin/clang+0x1a75628)
>> #18 0x0000000001a37181 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (llvm.inst/bin/clang+0x1a37181)
>> #19 0x0000000001b06501 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (llvm.inst/bin/clang+0x1b06501)
>> #20 0x000000000080e433 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (llvm.inst/bin/clang+0x80e433)
>> #21 0x000000000080c997 main (llvm.inst/bin/clang+0x80c997)
>> #22 0x00007f6949ba6a40 __libc_start_main /build/buildd/glibc-2.21/csu/libc-start.c:323:0
>> #23 0x0000000000809479 _start (llvm.inst/bin/clang+0x809479)
>> I'll try to come up with a reduced testcase this afternoon.
>> 
>> -Eli
>> -- 
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <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/20171004/938bad22/attachment.html>