Page MenuHomePhabricator

[PGO] Profile guided code size optimization.
ClosedPublic

Authored by yamauchi on Mar 18 2019, 2:21 PM.

Details

Summary

Enable some of the existing size optimizations for cold code under PGO.

A ~5% code size saving in big internal app under PGO.

The way it gets BFI/PSI is discussed in the RFC thread

http://lists.llvm.org/pipermail/llvm-dev/2019-March/130894.html

Note it doesn't currently touch loop passes.

Diff Detail

Event Timeline

yamauchi created this revision.Mar 18 2019, 2:21 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 18 2019, 2:21 PM

Missing unit tests for the feature.

lib/Analysis/ProfileSummaryInfo.cpp
337 ↗(On Diff #191176)

BB can still be 'not cold' even though the function entry is cold.

Or perhaps you should assert BB == nullptr and use

PSI->isFunctionColdInCallGraph() interface.

lib/Transforms/Scalar/LoopLoadElimination.cpp
539

is BFI null check needed?

lib/Transforms/Scalar/LoopUnrollPass.cpp
207

Do you need to check BFI here? It is already checked in shouldOptimizeForSize

yamauchi updated this revision to Diff 191591.Mar 20 2019, 2:46 PM
yamauchi marked 3 inline comments as done.

Addressed comments. Tests added.

Look fine in general. Easwaran can help with review of pass pipeline changes

lib/Transforms/Scalar/LoopLoadElimination.cpp
537–541

auto *HeaderBB = L->getHeader()->getParent();
bool OptForSize = HeaderBB->optForSize() || (PSI && BFI && PSI->shouldOptimizeForSize(HeaderBB));

yamauchi updated this revision to Diff 191773.Mar 21 2019, 1:42 PM
yamauchi marked an inline comment as done.

Address comment.

eraman added inline comments.Mar 21 2019, 4:38 PM
lib/Analysis/ProfileSummaryInfo.cpp
331 ↗(On Diff #191591)

This function looks very odd to me. Why not separate it into shouldOptimizeForSize(Function *, BFI) and shouldOptimizeForSize(BasicBlock*,...)? All but one uses of this function passes a BB in which case the function is irrrelevant.

62 ↗(On Diff #191773)

Perhaps better to default to false, do robust performance testing and flip the option. You've mentioned code size reduction in one binary in the description, but good to validate there are no performance regressions in spec.

lib/Transforms/Vectorize/LoopVectorize.cpp
7139–7140

Comment out of sync with the code

7222–7223

Augment the comment to make it in-sync with the code

yamauchi updated this revision to Diff 192382.Mar 26 2019, 3:52 PM
yamauchi marked 5 inline comments as done and an inline comment as not done.

address comments.

yamauchi added inline comments.Mar 26 2019, 3:54 PM
lib/Analysis/ProfileSummaryInfo.cpp
62 ↗(On Diff #191773)

Here's SPEC data.

400.perlbench
base: 512.81 ±0.564 (8 trials, 7.8 robust values)
test: 512.16 ±0.420 (8 trials, 7.1 robust values)
diff: -0.13% ±0.124%
Possible significant effect (p=0.047)

401.bzip2
base: 532.43 ±1.145 (8 trials, 7.9 robust values)
test: 532.81 ±0.962 (8 trials, 8.0 robust values)
diff: +0.07% ±0.254%
Not significant (p=0.567)

403.gcc
base: 313.08 ±1.356 (8 trials, 7.8 robust values)
test: 312.63 ±1.183 (8 trials, 7.5 robust values)
diff: -0.14% ±0.519%
Not significant (p=0.558)

429.mcf
base: 239.39 ±3.018 (8 trials, 8.0 robust values)
test: 239.41 ±2.067 (8 trials, 8.0 robust values)
diff: +0.01% ±1.386%
High variance between trials

445.gobmk
base: 560.88 ±0.613 (8 trials, 8.0 robust values)
test: 560.46 ±0.143 (7 trials, 6.0 robust values)
diff: -0.07% ±0.103%
Not significant (p=0.142)

456.hmmer
base: 602.40 ±0.140 (8 trials, 7.7 robust values)
test: 602.45 ±0.074 (8 trials, 7.5 robust values)
diff: +0.01% ±0.024%
Not significant (p=0.441)

458.sjeng
base: 607.02 ±0.957 (8 trials, 7.5 robust values)
test: 606.24 ±0.599 (8 trials, 7.5 robust values)
diff: -0.13% ±0.167%
Not significant (p=0.123)

462.libquantum
base: 291.97 ±4.636 (8 trials, 8.0 robust values)
test: 290.80 ±3.281 (8 trials, 7.6 robust values)
diff: -0.40% ±1.765%
High variance between trials

464.h264ref
base: 795.35 ±0.658 (8 trials, 7.9 robust values)
test: 795.05 ±0.345 (8 trials, 8.0 robust values)
diff: -0.04% ±0.085%
Not significant (p=0.354)

471.omnetpp
base: 274.20 ±5.967 (8 trials, 6.1 robust values)
test: 271.89 ±7.348 (8 trials, 6.6 robust values)
diff: -0.85% ±3.043%
High variance between trials

473.astar
base: 426.80 ±0.802 (8 trials, 7.8 robust values)
test: 425.75 ±0.526 (8 trials, 6.1 robust values)
diff: -0.25% ±0.202%
Possible significant effect (p=0.021)

483.xalancbmk
base: 250.64 ±1.038 (8 trials, 8.0 robust values)
test: 250.19 ±0.530 (8 trials, 6.9 robust values)
diff: -0.18% ±0.422%
Not significant (p=0.380)

lib/Transforms/Scalar/LoopLoadElimination.cpp
539

It is now.

lib/Transforms/Scalar/LoopUnrollPass.cpp
207

It is now.

Easwaran and David, more comments?

eraman added inline comments.Apr 2 2019, 2:39 PM
lib/Analysis/ProfileSummaryInfo.cpp
335 ↗(On Diff #192382)

This check is not needed as isFunctionColdInCallGraph first checks if summary is available.

I am not convinced this shouldOptimizeForSize belongs to ProfileSummaryInfo but I don't have any good suggestions. One possibility is to keep the flag in PassBuilder and pass it to individual passes which then check the boolean and isFunctionColdInCallGraph. Or perhaps add a pass that annotates OptForSize attribute on functions based on profile data? (that will still not help with the BB version of this function). Thoughts?

yamauchi marked an inline comment as done.Apr 3 2019, 10:16 AM
yamauchi added inline comments.
lib/Analysis/ProfileSummaryInfo.cpp
335 ↗(On Diff #192382)

This check is not needed as isFunctionColdInCallGraph first checks if summary is available.

True. I'd prefer having it here to make it clearer that we only do this with PGO. But it can go either way here.

I am not convinced this shouldOptimizeForSize belongs to ProfileSummaryInfo but I don't have any good suggestions. One possibility is to keep the flag in PassBuilder and pass it to individual passes which then check the boolean and isFunctionColdInCallGraph. Or perhaps add a pass that annotates OptForSize attribute on functions based on profile data? (that will still not help with the BB version of this function). Thoughts?

I agree - this may not belong to ProfileSummaryInfo. I think I put it there because it's tied to the existence of PSI and might potentially need access to some PSI-internal data or have opportunities for code sharing.

How about having a separate file like ProfileGuidedSizeOpt.h/cpp which hosts the flag and shouldOptimizeForSize, and more? I think that would have an advantage of being able to share the common code in a single place (calling isFunctionColdInCallGraph, etc.) and being less intrusive (not needing to change many pass constructors, etc.), and being able to handle the block-level profiles (unlike the OptForSize attribute).

I'm not sure which directory it could be in, as that would have an implication on the cross-directory dependencies (eg. if we want to use PSI/BB/MBB/BFI/MBFI as a parameter type in it, it must be somewhere above IR/Analysis/CodeGen yet accessible from Transform/CodeGen.). Is there some directory where this sort of files can be in?

...it must be somewhere above IR/Analysis/CodeGen yet accessible from Transform/CodeGen....

Having scanned the LLVMBuild.txt files for the dependencies, I think one workable way would be a split between two parts, something like:

1 lib/Transforms/Utils/SizeOpts - the flag and the 'shouldOptimizeFor' for the IR passes.
2 lib/CodeGen/MachineSizeOpts - the 'shouldOptimizeFor' for the CodeGen/Machine IR passes.

Note 2 depends on 1. 1 is sufficient for this patch.

Thoughts?

yamauchi updated this revision to Diff 193941.Apr 5 2019, 12:33 PM

Moved the code out of ProfileSummaryInfo to separate files. PTAL.

eraman added inline comments.Apr 10 2019, 12:33 PM
lib/Transforms/Utils/SizeOpts.cpp
24

In a follow-up patch, it might be good to make this work for the non-profile case and call this whereever F->optForSize() is used.

28

Instead of the asserts, return false if any one of them is null. This will avoid doing if (PSI && BFI && shouldOptimizeForSize(...)) in the callers.

test/Transforms/ConstantHoisting/ARM/const-addr-no-neg-offset.ll
50

Perhaps add a CHECK: [[CONST2:%const_mat[0-9]*]] = add i32 %const, -4 to check the size optimization doesn't happen when -pgso is not used?

yamauchi marked 4 inline comments as done.Apr 11 2019, 10:37 AM
yamauchi added inline comments.
lib/Transforms/Utils/SizeOpts.cpp
24

Yes, it might be good.

yamauchi updated this revision to Diff 194715.Apr 11 2019, 10:37 AM
yamauchi marked an inline comment as done.

Addressed comments.

eraman accepted this revision.Apr 11 2019, 10:55 AM

LGTM after making the hasProfileSummary check consistent in both flavors of shouldOptimizeForSize

lib/Transforms/Utils/SizeOpts.cpp
35

The previous flavor of this function doesn't check !PSI->hasProfileSummary(). In both the versions, it is not necessary as isColdBlock and isFunctionColdInCallGraph return false if there is no summary. But if you choose to add the check, then do it in both the flavors of this function.

test/Transforms/ConstantHoisting/ARM/const-addr-no-neg-offset.ll
3

You don't need a separate run with explicit -pgso=false. You can use the first run and use CHECK and CHECK-LABEL where you use NPGSO and NPGO-LABEL . That's what I had in mind, but if you prefer this, it's fine.

This revision is now accepted and ready to land.Apr 11 2019, 10:55 AM
yamauchi marked 3 inline comments as done.Apr 11 2019, 3:00 PM
yamauchi added inline comments.
test/Transforms/ConstantHoisting/ARM/const-addr-no-neg-offset.ll
3

Sure. I think separate runs are probably better in that it doesn't matter what the default value of -pgso is.

yamauchi updated this revision to Diff 194772.Apr 11 2019, 3:01 PM
yamauchi marked an inline comment as done.

Addressed comments.

This revision was automatically updated to reflect the committed changes.
RolandF added a subscriber: RolandF.Mon, May 6, 9:24 AM

This revision causes a traceback when compiling SPEC2017 523.xalanbmk_r with -O3 -m64 -mcpu=power9 -flto and PGO, on the -fprofile-use compile step for XMLDateTime.cpp. Can you please take a look? Let me know if don't have access to SPEC0217 source and need a reproducer. The traceback was as follows:

  1. <eof> parser at end of file
  2. Optimizer #0 0x00007c86ec7ddfb4 PrintStackTraceSignalHandler(void*) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMSupport.so.9svn+0x1bdfb4) #1 0x00007c86ec7db1d8 llvm::sys::RunSignalHandlers() (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMSupport.so.9svn+0x1bb1d8) #2 0x00007c86ec7de400 SignalHandler(int) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMSupport.so.9svn+0x1be400) #3 0x00007c86f20104d8 (linux-vdso64.so.1+0x4d8) #4 0x00007c86eaaae98c libc_signal_restore_set /build/glibc-uvws04/glibc-2.27/signal/../sysdeps/unix/sysv/linux/nptl-signals.h:80:0 #5 0x00007c86eaaae98c raise /build/glibc-uvws04/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:48:0 #6 0x00007c86eaab0be0 abort /build/glibc-uvws04/glibc-2.27/stdlib/abort.c:79:0 #7 0x00007c86eaa9bb38 assert_fail_base /build/glibc-uvws04/glibc-2.27/assert/assert.c:92:0 #8 0x00007c86eaa9bbe4 __assert_fail /build/glibc-uvws04/glibc-2.27/assert/assert.c:101:0 #9 0x00007c86ee00ee84 llvm::BlockFrequencyInfoImplBase::analyzeIrreducible(llvm::bfi_detail::IrreducibleGraph const&, llvm::BlockFrequencyInfoImplBase::LoopData*, std::_List_iterator<llvm::BlockFrequencyInfoImplBase::LoopData>) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMAnalysis.so.9svn+0xdee84)

#10 0x00007c86ee00371c llvm::BlockFrequencyInfoImpl<llvm::BasicBlock>::computeIrreducibleMass(llvm::BlockFrequencyInfoImplBase::LoopData*, std::_List_iterator<llvm::BlockFrequencyInfoImplBase::LoopData>) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMAnalysis.so.9svn+0xd371c)
#11 0x00007c86edffa420 llvm::BlockFrequencyInfoImpl<llvm::BasicBlock>::calculate(llvm::Function const&, llvm::BranchProbabilityInfo const&, llvm::LoopInfo const&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMAnalysis.so.9svn+0xca420)
#12 0x00007c86edff9bdc llvm::BlockFrequencyInfo::calculate(llvm::Function const&, llvm::BranchProbabilityInfo const&, llvm::LoopInfo const&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMAnalysis.so.9svn+0xc9bdc)
#13 0x00007c86edffbda0 llvm::BlockFrequencyAnalysis::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMAnalysis.so.9svn+0xcbda0)
#14 0x00007c86e91fac88 llvm::detail::AnalysisPassModel<llvm::Function, llvm::BlockFrequencyAnalysis, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function>::Invalidator>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libLLVMPasses.so.9svn+0x7ac88)
#15 0x00007c86ed6914c8 llvm::AnalysisManager<llvm::Function>::getResultImpl(llvm::AnalysisKey*, llvm::Function&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMCore.so.9svn+0x2914c8)
#16 0x00007c86ed09afe4 llvm::InstCombinePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMInstCombine.so.9svn+0x2afe4)
#17 0x00007c86e920b76c llvm::detail::PassModel<llvm::Function, llvm::InstCombinePass, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libLLVMPasses.so.9svn+0x8b76c)
#18 0x00007c86ed68cfb0 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> >::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMCore.so.9svn+0x28cfb0)
#19 0x00007c86e921a500 llvm::CGSCCToFunctionPassAdaptor<llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function> > >::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libLLVMPasses.so.9svn+0x9a500)
#20 0x00007c86ee0462c8 llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&>::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMAnalysis.so.9svn+0x1162c8)
#21 0x00007c86e922addc llvm::DevirtSCCRepeatedPass<llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&> >::run(llvm::LazyCallGraph::SCC&, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>&, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libLLVMPasses.so.9svn+0xaaddc)
#22 0x00007c86e922a150 llvm::ModuleToPostOrderCGSCCPassAdaptor<llvm::DevirtSCCRepeatedPass<llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&> > >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libLLVMPasses.so.9svn+0xaa150)
#23 0x00007c86e922972c llvm::detail::PassModel<llvm::Module, llvm::ModuleToPostOrderCGSCCPassAdaptor<llvm::DevirtSCCRepeatedPass<llvm::PassManager<llvm::LazyCallGraph::SCC, llvm::AnalysisManager<llvm::LazyCallGraph::SCC, llvm::LazyCallGraph&>, llvm::LazyCallGraph&, llvm::CGSCCUpdateResult&> > >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libLLVMPasses.so.9svn+0xa972c)
#24 0x00007c86ed68b330 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMCore.so.9svn+0x28b330)
#25 0x00007c86e9236aac llvm::detail::PassModel<llvm::Module, llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >, llvm::PreservedAnalyses, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libLLVMPasses.so.9svn+0xb6aac)
#26 0x00007c86ed68b330 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module> >::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libLLVMCore.so.9svn+0x28b330)
#27 0x00007c86eb7863d4 (anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangCodeGen.so.9svn+0x963d4)
#28 0x00007c86eb780060 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> >) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangCodeGen.so.9svn+0x90060)
#29 0x00007c86eba84058 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangCodeGen.so.9svn+0x394058)
#30 0x00007c86e902e884 clang::ParseAST(clang::Sema&, bool, bool) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/../lib/libclangParse.so.9svn+0x2e884)
#31 0x00007c86eb4245a8 clang::ASTFrontendAction::ExecuteAction() (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangFrontend.so.9svn+0xe45a8)
#32 0x00007c86eba82738 clang::CodeGenAction::ExecuteAction() (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangCodeGen.so.9svn+0x392738)
#33 0x00007c86eb423c70 clang::FrontendAction::Execute() (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangFrontend.so.9svn+0xe3c70)
#34 0x00007c86eb3cf5e4 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangFrontend.so.9svn+0x8f5e4)
#35 0x00007c86eb314340 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/../lib/libclangFrontendTool.so.9svn+0x4340)
#36 0x0000000010013b38 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/clang-9+0x10013b38)
#37 0x00000000100111b0 main (/compgpfs/builds/continuous.dev/ppc64le/ubuntu16/wyvern.dev.release/228/bin/clang-9+0x100111b0)
#38 0x00007c86eaa8441c generic_start_main /build/glibc-uvws04/glibc-2.27/csu/../csu/libc-start.c:310:0
#39 0x00007c86eaa84618 __libc_start_main /build/glibc-uvws04/glibc-2.27/csu/../sysdeps/unix/sysv/linux/powerpc/libc-start.c:116:0
clang-9: error: unable to execute command: Aborted (core dumped)
clang-9: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 9.0.0 (git@github.ibm.com:compiler/llvm-project.git 480fcb96a95fd1caad55f6da2ee1317ce81eade9)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix

Yes, please send a reproducer.

The following file and command should reproduce the failure we are seeing.


opt --passes='default<O3>' crash.ll -o crash.bc

It looked like a latent bug in jump threading. Uploaded a fix https://reviews.llvm.org/D61920