This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Use variadic debug values to salvage BinOps and GEP instrs with non-const operands
ClosedPublic

Authored by StephenTozer on Nov 18 2020, 8:50 AM.

Details

Summary

This patch follows the complete implementation of variadic debug values, making use of them to salvage arithmetic operations with two or more non-const operands; this includes the GetElementPtr instruction, and most Binary Operator instructions.

The majority of the real work in this patch is in Local.cpp, where the salvage function has been expanded in complexity for GEP and BinOp instructions, which have thus been refactored out into separate functions. The GEP implementation required the creation of a new function collectOffset which behaves similarly to accumulateConstantOffset, except that in addition to any constant offset it also fetches any non-constant offsets and returns them in a map of [SSA Value -> Factor].

Outside of these larger changes, the remainder of this patch consists of small utility functions used in salvaging, and updating uses of the salvage functions. Not all places that use salvaging have been updated to make use of variadic salvaging yet (such as salvaging in ISel), as additional changes need to be made in those areas to support this form of salvaging. They should not be difficult to implement in future, however.

Diff Detail

Event Timeline

StephenTozer created this revision.Nov 18 2020, 8:50 AM
StephenTozer requested review of this revision.Nov 18 2020, 8:50 AM
StephenTozer added inline comments.Nov 18 2020, 8:55 AM
llvm/test/Transforms/Reassociate/undef_intrinsics_when_deleting_instructions.ll
-22–25

A note for reviewers on the changes made to this test: this test has been modified to prevent it failing after this patch is applied. The failure introduced by this patch is not an error, but the opposite: the test relies on intrinsics being made undef when the instruction they relied on is deleted, but as of this patch we are able to salvage them so they will not be set undef. In order to preserve the spirit of this test, I changed it to instead reassociate float arithmetic instructions, which cannot currently be salvaged and so results in the intrinsic being undef'd like before.

dstenb added a subscriber: dstenb.Nov 18 2020, 9:24 AM

Exciting!

I took the liberty to add some review comments whilst familiarizing myself with the code.

llvm/lib/IR/DebugInfoMetadata.cpp
26

Nit: std::max(Result, ExprOp.getArg(0) + 1) ?

llvm/lib/Transforms/Utils/Local.cpp
49–1

Could the creation of this utility function and getSalvageOpsForBinOp be done as a preceding NFC refactoring commit? Just to make it slightly easier to see what the difference in behavior is.

81–82

Should this say DIExpression perhaps? DWARFv5 supports binary operations on base types wider than 64 bits, but LLVM does not support such expressions.

(minor drive-by comment, but I'm not the right person to do more in depth review of this patch, unfortunately)

llvm/test/Transforms/Reassociate/undef_intrinsics_when_deleting_instructions.ll
-22–25

Any chance of using something that'd be even more robust by using, for instance, a call to an external 'pure' function where the return value is used to define the debug value, but is otherwise unused - there would the instruction could be deleted but there would be no way the value could be reconstituted no matter how much we improve debug info in the future

Thanks!! So, this should be the most important one :) I would really like to see some measurements (e.g. llvm-locstats) before/after this patch.
Have you tried building llvm-project itself with this?

(Neither arc patch D91722 nor curl -L 'https://reviews.llvm.org/D91722?download=1' | patch -p1 can apply the patch locally. Can you upload via arc diff or git format-patch?)

This is nice!

llvm/lib/Transforms/Utils/Local.cpp
112

Nit: Instead of having 20 calls to push_back, would it make sense to have a helper function that just does switch(opcode) { case Instruction::Add: return dwarf::DW_OP_plus; ...}?

StephenTozer added inline comments.Dec 3 2020, 6:17 AM
llvm/test/Transforms/Reassociate/undef_intrinsics_when_deleting_instructions.ll
-22–25

In a more general case I'd say so, but this behaviour in the reassociate pass is stimulated by arithmetic instructions, rather than just dead code in general; making use of float arithmetic in this case seemed to be the shortest path.

Thanks!! So, this should be the most important one :) I would really like to see some measurements (e.g. llvm-locstats) before/after this patch.
Have you tried building llvm-project itself with this?

So far I've tested this with the benchmarks from the llvm test suite (specifically the CTMark projects, since we're looking for compilation metrics only). I'll post a more complete set of stats soon, but the summary is that there is a small increase in compile time for most projects; <1% or outright negligible in most cases. In terms of locstats, the change looks to add a modest 1-2% increase in overall variable coverage for most projects, although a notable exception is tramp3d-v4 which saw variable coverage change from 53%=>66% - a fairly substantial improvement.

I'm optimistic about further improvements to the locstats following from this work; the current patch doesn't update any of the existing salvaging in Instruction Selection to support variadic locations (they require some specific changes which aren't complicated but require a separate patch), and also enable some new salvaging opportunities in Instruction Selection and the loop passes (such as Loop Strength Reduce).

Rebased onto recent master, no functional changes; moved the salvageDebugInfoImpl refactoring into a separate NFC patch; addressed outstanding review comments.

aprantl added inline comments.Dec 10 2020, 8:48 AM
llvm/include/llvm/IR/DebugInfoMetadata.h
23

to be in line with the other method names: getNumLocationOperands() or getNumLocationRefs() or getNumArgOps()...?
If wee get super nerdy, I think technically these are operators (that operate on the DWARF stack) and not operands :-)

StephenTozer added inline comments.Dec 10 2020, 9:50 AM
llvm/include/llvm/IR/DebugInfoMetadata.h
23

Sounds good to me! And wrt the nerdy point, I think that's actually an advantageous semantic point here: the intent of this function is actually to get the number of location operands that the DIExpression refers to, as opposed to the number of actual operators of a given type (i.e. for the nonsensical expression DIExpression(DW_OP_LLVM_arg 0, DW_OP_LLVM_arg 0, DW_OP_LLVM_arg 0) we still only refer to one location operand).

Thanks!! So, this should be the most important one :) I would really like to see some measurements (e.g. llvm-locstats) before/after this patch.
Have you tried building llvm-project itself with this?

So far I've tested this with the benchmarks from the llvm test suite (specifically the CTMark projects, since we're looking for compilation metrics only). I'll post a more complete set of stats soon, but the summary is that there is a small increase in compile time for most projects; <1% or outright negligible in most cases. In terms of locstats, the change looks to add a modest 1-2% increase in overall variable coverage for most projects, although a notable exception is tramp3d-v4 which saw variable coverage change from 53%=>66% - a fairly substantial improvement.

I'm optimistic about further improvements to the locstats following from this work; the current patch doesn't update any of the existing salvaging in Instruction Selection to support variadic locations (they require some specific changes which aren't complicated but require a separate patch), and also enable some new salvaging opportunities in Instruction Selection and the loop passes (such as Loop Strength Reduce).

Very cool! Thanks!

Rebased onto recent master, fixed test failures.

Ping - any further comments?

aprantl accepted this revision.Feb 1 2021, 5:33 PM

I think this looks pretty good. I found on last comment about the function signature of collectOffset, but otherwise this is fine.

llvm/include/llvm/IR/Instructions.h
5

Any reason why this doesn't just return an Optional<APInt>?

This revision is now accepted and ready to land.Feb 1 2021, 5:33 PM

Rebased onto latest master.

Modified salvageDebugInfoForDbgValues to only produce DIArgLists for dbg.values, and not dbg.addr or dbg.declare. This is necessary for the time being, as the current implementation of variadic debug values only works with DW_OP_stack_value for reasons previously discussed on the mailing list and in the root patch of this stack. In the next patch to follow, which will make the current DBG_VALUE_LIST into the default debug value instruction, the DIExpression representation will be changed to support non-stack_value variadic debug values, and this change can be reverted.

Minor update to fix an error in a comment (dbg.value -> dbg.declare).

StephenTozer added inline comments.Mar 10 2021, 2:32 PM
llvm/lib/Transforms/Utils/Local.cpp
1751

This else block will be removed in the near future, so I've tried to minimize the amount of change to the function, rather than rewriting a greater portion around this.

jmorse added a subscriber: jmorse.Mar 11 2021, 4:46 AM

Modified salvageDebugInfoForDbgValues to only produce DIArgLists for dbg.values, and not dbg.addr or dbg.declare. This is necessary for the time being, as the current implementation of variadic debug values only works with DW_OP_stack_value for reasons previously discussed on the mailing list and in the root patch of this stack. In the next patch to follow, which will make the current DBG_VALUE_LIST into the default debug value instruction, the DIExpression representation will be changed to support non-stack_value variadic debug values, and this change can be reverted.

SGTM

This revision was landed with ongoing or failed builds.Mar 11 2021, 5:34 AM
This revision was automatically updated to reflect the committed changes.

Fixes two issues with handling of variadic debug values:

  1. SelectionDAG::transferDebugValues incorrectly updating its dependencies list.
  2. LoopStrengthReduce, when trying to "repair" undef debug values by replacing them with equal values, must first restore the original location metadata to prevent it from being incorrectly updated if the number of location operands changed as a result of salvaging by LSR.

I'm seeing a crash after the most recent time this was re-applied in 791930d74087b8ae8901172861a0fd21a211e436. The crash is when compiling https://github.com/beltoforion/muparser/blob/master/src/muParserTest.cpp, but I'm reducing it now, as the error might also depend on how we build that internally (we use at least`-g -O3`)

The assertion printed when crashing is:

assert.h assertion failed at llvm/lib/CodeGen/LiveDebugVariables.cpp:128 in (anonymous namespace)::DbgVariableValue::DbgVariableValue(ArrayRef<unsigned int>, bool, bool, const llvm::DIExpression &): LocNoVec.size() < 64 && "debug value containing 64+ unique machine locations is not " "supported by Live Debug Variables"

Here's a C++ repro

$ cat repro.cc
class h {
 public:
  h(const char *);
  ~h();
};

int j(h);
int k();

int func() {
  int l = k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  l += k();
  j("");
  return l;
}

$ clang++ -g -O1 -c repro.cc
clang++: /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/LiveDebugVariables.cpp:128: (anonymous namespace)::DbgVariableValue::DbgVariableValue(ArrayRef<unsigned int>, bool, bool, const llvm::DIExpression &): Assertion `LocNoVec.size() < 64 && "debug value containing 64+ unique machine locations is not " "supported by Live Debug Variables"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /home/rupprecht/dev/clang++ -g -O1 -c repro.cc
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'repro.cc'.
4.      Running pass 'Debug Variable Analysis' on function '@_Z4funcv'
...
#12 0x0000000008508a60 (anonymous namespace)::DbgVariableValue::DbgVariableValue(llvm::ArrayRef<unsigned int>, bool, bool, llvm::DIExpression const&) /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/LiveDebugVariables.cpp:129:18
#13 0x0000000008505fff (anonymous namespace)::UserValue::addDef(llvm::SlotIndex, llvm::ArrayRef<llvm::MachineOperand>, bool, bool, llvm::DIExpression const&) /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/LiveDebugVariables.cpp:403:22
#14 0x0000000008505976 (anonymous namespace)::LDVImpl::handleDebugValue(llvm::MachineInstr&, llvm::SlotIndex) /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/LiveDebugVariables.cpp:814:5
#15 0x00000000085050d8 (anonymous namespace)::LDVImpl::collectDebugValues(llvm::MachineFunction&) /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/LiveDebugVariables.cpp:887:68
#16 0x0000000008503983 (anonymous namespace)::LDVImpl::runOnMachineFunction(llvm::MachineFunction&) /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/LiveDebugVariables.cpp:1208:18
#17 0x00000000085036f8 llvm::LiveDebugVariables::runOnMachineFunction(llvm::MachineFunction&) /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/LiveDebugVariables.cpp:1236:3
#18 0x00000000081aced7 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) /home/rupprecht/src/llvm-project/llvm/lib/CodeGen/MachineFunctionPass.cpp:72:8
#19 0x0000000008824f9e llvm::FPPassManager::runOnFunction(llvm::Function&) /home/rupprecht/src/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1439:23
#20 0x0000000008829cf2 llvm::FPPassManager::runOnModule(llvm::Module&) /home/rupprecht/src/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1485:16
#21 0x0000000008825889 (anonymous namespace)::MPPassManager::runOnModule(llvm::Module&) /home/rupprecht/src/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:1554:23
...
StephenTozer added a comment.EditedApr 27 2021, 3:00 AM

I'm seeing a crash after the most recent time this was re-applied in 791930d74087b8ae8901172861a0fd21a211e436. The crash is when compiling https://github.com/beltoforion/muparser/blob/master/src/muParserTest.cpp, but I'm reducing it now, as the error might also depend on how we build that internally (we use at least`-g -O3`)

Thanks for the report, and the handy reproducer! I'll upload a fix momentarily; it looks as though there's an extremely complex debug value being produced that tries to use more than 64 different return values. This hits a built-in limit on the number of allowed locations in LiveDebugVariables, added for performance reasons; we didn't expect to actually hit the capacity limit, but now that we know it's entirely possible to do so I'll either remove the assert and make sure the debug value is dropped instead, or expand the capacity limit. The latter would be preferred, but could cause performance issues with the current implementation of LiveDebugVariables; once I've determined whether or not anything will break from doing so, I'll push up the appropriate fix.

I'm seeing a crash after the most recent time this was re-applied in 791930d74087b8ae8901172861a0fd21a211e436.

This issue should now be fixed as of revision rGb622df3c9398 - the build should be totally fixed, but let me know if any further errors appear relating to this.

This patch as 791930d74087b8ae8901172861a0fd21a211e436 causes assertion failures with several x86 Linux kernel configurations and a 32-bit ARM configuration:

$ curl -LSso .config https://github.com/archlinux/svntogit-packages/raw/packages/linux/trunk/config

$ make -skj"$(nproc)" LLVM=1 LLVM_IAS=1 olddefconfig arch/x86/events/intel/ds.o
clang-13: /home/nathan/cbl/github/tc-build/llvm-project/llvm/include/llvm/CodeGen/SelectionDAGNodes.h:1105: llvm::SDValue::SDValue(llvm::SDNode *, unsigned int): Assertion `(!Node || !ResNo || ResNo < Node->getNumValues()) && "Invalid result number for the given node!"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name ds.c -mrelocation-model static -fno-delete-null-pointer-checks -mllvm -warn-stack-size=2048 -mframe-pointer=none -relaxed-aliasing -fmath-errno -fno-rounding-math -no-integrated-as -mconstructor-aliases -mcmodel=kernel -target-cpu x86-64 -target-feature +retpoline-indirect-calls -target-feature +retpoline-indirect-branches -target-feature -sse -target-feature -mmx -target-feature -sse2 -target-feature -3dnow -target-feature -avx -target-feature -x87 -target-feature +retpoline-external-thunk -disable-red-zone -tune-cpu generic -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -fcoverage-compilation-dir=/home/nathan/cbl/src/linux-stable -nostdsysteminc -nobuiltininc -resource-dir /home/nathan/cbl/github/tc-build/build/llvm/stage1/lib/clang/13.0.0 -dependency-file arch/x86/events/intel/.ds.o.d -MT arch/x86/events/intel/ds.o -isystem /home/nathan/cbl/github/tc-build/build/llvm/stage1/lib/clang/13.0.0/include -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -I ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D CC_USING_NOP_MCOUNT -D CC_USING_FENTRY -D KBUILD_MODFILE=\"arch/x86/events/intel/ds\" -D KBUILD_BASENAME=\"ds\" -D KBUILD_MODNAME=\"ds\" -D __KBUILD_MODNAME=kmod_ds -fmacro-prefix-map=./= -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -Werror=unknown-warning-option -Wno-sign-compare -Wno-frame-address -Wno-address-of-packed-member -Wno-format-invalid-specifier -Wno-gnu -Wno-unused-const-variable -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-pointer-to-enum-cast -Wno-tautological-constant-out-of-range-compare -std=gnu89 -fno-dwarf-directory-asm -fdebug-compilation-dir=/home/nathan/cbl/src/linux-stable -ferror-limit 19 -pg -mfentry -fwrapv -stack-protector 2 -mstack-alignment=8 -fcf-protection=none -fwchar-type=short -fno-signed-wchar -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops -vectorize-slp -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/ds-e46a9b.s -x c arch/x86/events/intel/ds.c
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module 'arch/x86/events/intel/ds.c'.
4.	Running pass 'X86 DAG->DAG Instruction Selection' on function '@intel_pmu_enable_bts'
 #0 0x00000000029dc9c3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x29dc9c3)
 #1 0x00000000029da82e llvm::sys::RunSignalHandlers() (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x29da82e)
 #2 0x00000000029dce8a SignalHandler(int) Signals.cpp:0:0
 #3 0x00007ff60aaf2960 __restore_rt sigaction.c:0:0
 #4 0x00007ff60a5e4ef5 raise (/usr/lib/libc.so.6+0x3cef5)
 #5 0x00007ff60a5ce862 abort (/usr/lib/libc.so.6+0x26862)
 #6 0x00007ff60a5ce747 _nl_load_domain.cold loadmsgcat.c:0:0
 #7 0x00007ff60a5dd646 (/usr/lib/libc.so.6+0x35646)
 #8 0x000000000396d4eb ProcessSDDbgValues(llvm::SDNode*, llvm::SelectionDAG*, llvm::InstrEmitter&, llvm::SmallVectorImpl<std::pair<unsigned int, llvm::MachineInstr*> >&, llvm::DenseMap<llvm::SDValue, llvm::Register, llvm::DenseMapInfo<llvm::SDValue>, llvm::detail::DenseMapPair<llvm::SDValue, llvm::Register> >&, unsigned int) ScheduleDAGSDNodes.cpp:0:0
 #9 0x000000000396b8ce llvm::ScheduleDAGSDNodes::EmitSchedule(llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x396b8ce)
#10 0x000000000394b2ce llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x394b2ce)
#11 0x00000000039488c1 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x39488c1)
#12 0x0000000003945151 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x3945151)
#13 0x0000000001ab0f45 (anonymous namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) X86ISelDAGToDAG.cpp:0:0
#14 0x0000000001e814fd llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x1e814fd)
#15 0x000000000231d188 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x231d188)
#16 0x00000000023256d1 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x23256d1)
#17 0x000000000231dc51 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x231dc51)
#18 0x00000000030603f3 (anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) BackendUtil.cpp:0:0
#19 0x000000000305a49d 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> >) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x305a49d)
#20 0x0000000003526e29 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) CodeGenAction.cpp:0:0
#21 0x0000000003e4fcf4 clang::ParseAST(clang::Sema&, bool, bool) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x3e4fcf4)
#22 0x000000000347e200 clang::FrontendAction::Execute() (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x347e200)
#23 0x00000000033b82aa clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x33b82aa)
#24 0x0000000003520d48 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x3520d48)
#25 0x00000000018577fc cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x18577fc)
#26 0x00000000018551bd ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) driver.cpp:0:0
#27 0x0000000001854f15 main (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x1854f15)
#28 0x00007ff60a5cfb25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#29 0x0000000001851e0e _start (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x1851e0e)
clang-13: error: unable to execute command: Aborted (core dumped)
clang-13: error: clang frontend command failed due to signal (use -v to see invocation)
ClangBuiltLinux clang version 13.0.0 (https://github.com/llvm/llvm-project 791930d74087b8ae8901172861a0fd21a211e436)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/nathan/cbl/github/tc-build/build/llvm/stage1/bin
clang-13: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-13: note: diagnostic msg: /tmp/ds-6ee420.c
clang-13: note: diagnostic msg: /tmp/ds-6ee420.sh
clang-13: note: diagnostic msg: 

********************
make[4]: *** [scripts/Makefile.build:271: arch/x86/events/intel/ds.o] Error 254
make[4]: Target '__build' not remade because of errors.
make[3]: *** [scripts/Makefile.build:514: arch/x86/events/intel] Error 2
make[3]: Target '__build' not remade because of errors.
make[2]: *** [scripts/Makefile.build:514: arch/x86/events] Error 2
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1851: arch/x86] Error 2
make[1]: Target 'arch/x86/events/intel/ds.o' not remade because of errors.
make: *** [Makefile:335: __build_one_by_one] Error 2
make: Target 'olddefconfig' not remade because of errors.
make: Target 'arch/x86/events/intel/ds.o' not remade because of errors.
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 distclean aspeed_g5_defconfig kernel/fork.o
clang-13: /home/nathan/cbl/github/tc-build/llvm-project/llvm/include/llvm/CodeGen/MachineRegisterInfo.h:830: void llvm::MachineRegisterInfo::updateDbgUsersToReg(llvm::Register, ArrayRef<llvm::MachineInstr *>) const: Assertion `MI->getOperand(0).isReg()' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13 -cc1 -triple armv6k-unknown-linux-gnueabi -S -disable-free -main-file-name fork.c -mrelocation-model static -meabi gnu -fno-delete-null-pointer-checks -mllvm -warn-stack-size=1024 -mframe-pointer=all -relaxed-aliasing -fmath-errno -fno-rounding-math -no-integrated-as -mconstructor-aliases -munwind-tables -target-cpu mpcore -target-feature +soft-float -target-feature +soft-float-abi -target-feature -vfp2 -target-feature -vfp2sp -target-feature -vfp3 -target-feature -vfp3d16 -target-feature -vfp3d16sp -target-feature -vfp3sp -target-feature -fp16 -target-feature -vfp4 -target-feature -vfp4d16 -target-feature -vfp4d16sp -target-feature -vfp4sp -target-feature -fp-armv8 -target-feature -fp-armv8d16 -target-feature -fp-armv8d16sp -target-feature -fp-armv8sp -target-feature -fullfp16 -target-feature -fp64 -target-feature -d32 -target-feature -neon -target-feature -crypto -target-feature -dotprod -target-feature -fp16fml -target-feature -bf16 -target-feature -mve -target-feature -mve.fp -target-feature -fpregs -target-feature +strict-align -target-abi aapcs-linux -msoft-float -mfloat-abi soft -mllvm -arm-global-merge=false -fallow-half-arguments-and-returns -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -fcoverage-compilation-dir=/home/nathan/cbl/src/linux-stable -nostdsysteminc -nobuiltininc -resource-dir /home/nathan/cbl/github/tc-build/build/llvm/stage1/lib/clang/13.0.0 -dependency-file kernel/.fork.o.d -MT kernel/fork.o -isystem /home/nathan/cbl/github/tc-build/build/llvm/stage1/lib/clang/13.0.0/include -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -I ./arch/arm/include -I ./arch/arm/include/generated -I ./include -I ./arch/arm/include/uapi -I ./arch/arm/include/generated/uapi -I ./include/uapi -I ./include/generated/uapi -D __KERNEL__ -D __LINUX_ARM_ARCH__=6 -U arm -D KBUILD_MODFILE=\"kernel/fork\" -D KBUILD_BASENAME=\"fork\" -D KBUILD_MODNAME=\"fork\" -D __KBUILD_MODNAME=kmod_fork -fmacro-prefix-map=./= -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -Werror=unknown-warning-option -Wno-frame-address -Wno-address-of-packed-member -Wno-format-invalid-specifier -Wno-gnu -Wno-unused-const-variable -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-array-bounds -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-pointer-to-enum-cast -Wno-tautological-constant-out-of-range-compare -std=gnu89 -fno-dwarf-directory-asm -fdebug-compilation-dir=/home/nathan/cbl/src/linux-stable -ferror-limit 19 -pg -fwrapv -stack-protector 2 -fno-signed-char -fwchar-type=short -fno-signed-wchar -fgnuc-version=4.2.1 -fcolor-diagnostics -vectorize-loops -vectorize-slp -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/fork-960b24.s -x c kernel/fork.c
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module 'kernel/fork.c'.
4.	Running pass 'Machine Copy Propagation Pass' on function '@copy_init_mm'
 #0 0x0000000002e414c3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x2e414c3)
 #1 0x0000000002e3f32e llvm::sys::RunSignalHandlers() (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x2e3f32e)
 #2 0x0000000002e4198a SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f40920e8960 __restore_rt sigaction.c:0:0
 #4 0x00007f4091bdaef5 raise (/usr/lib/libc.so.6+0x3cef5)
 #5 0x00007f4091bc4862 abort (/usr/lib/libc.so.6+0x26862)
 #6 0x00007f4091bc4747 _nl_load_domain.cold loadmsgcat.c:0:0
 #7 0x00007f4091bd3646 (/usr/lib/libc.so.6+0x35646)
 #8 0x00000000024dbf26 (anonymous namespace)::MachineCopyPropagation::runOnMachineFunction(llvm::MachineFunction&) MachineCopyPropagation.cpp:0:0
 #9 0x0000000002300fdd llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x2300fdd)
#10 0x0000000002780de8 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x2780de8)
#11 0x0000000002789331 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x2789331)
#12 0x00000000027818b1 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x27818b1)
#13 0x00000000034c4dd3 (anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) BackendUtil.cpp:0:0
#14 0x00000000034bee7d 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> >) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x34bee7d)
#15 0x000000000398b579 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) CodeGenAction.cpp:0:0
#16 0x00000000042b47b4 clang::ParseAST(clang::Sema&, bool, bool) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x42b47b4)
#17 0x00000000038e2970 clang::FrontendAction::Execute() (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x38e2970)
#18 0x000000000381ca1a clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x381ca1a)
#19 0x0000000003985498 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x3985498)
#20 0x0000000001ab19d5 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x1ab19d5)
#21 0x0000000001aaf37d ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) driver.cpp:0:0
#22 0x0000000001aaf0d5 main (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x1aaf0d5)
#23 0x00007f4091bc5b25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#24 0x0000000001aabfce _start (/home/nathan/cbl/github/tc-build/build/llvm/stage1/bin/clang-13+0x1aabfce)
clang-13: error: unable to execute command: Aborted (core dumped)
clang-13: error: clang frontend command failed due to signal (use -v to see invocation)
ClangBuiltLinux clang version 13.0.0 (https://github.com/llvm/llvm-project 791930d74087b8ae8901172861a0fd21a211e436)
Target: arm-unknown-linux-gnueabi
Thread model: posix
InstalledDir: /home/nathan/cbl/github/tc-build/build/llvm/stage1/bin
clang-13: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-13: note: diagnostic msg: /tmp/fork-a2b208.c
clang-13: note: diagnostic msg: /tmp/fork-a2b208.sh
clang-13: note: diagnostic msg: 

********************
make[2]: *** [scripts/Makefile.build:271: kernel/fork.o] Error 254
make[2]: Target '__build' not remade because of errors.
make[1]: *** [Makefile:1851: kernel] Error 2
make[1]: Target 'kernel/fork.o' not remade because of errors.
make: *** [Makefile:335: __build_one_by_one] Error 2
make: Target 'distclean' not remade because of errors.
make: Target 'aspeed_g5_defconfig' not remade because of errors.
make: Target 'kernel/fork.o' not remade because of errors.

A reduced reproducer for the first:

$ cat ds.i
intel_pmu_enable_bts_config, intel_pmu_enable_bts___trans_tmp_1,
    intel_pmu_enable_bts___ecx;
long intel_pmu_enable_bts___eax;
intel_pmu_enable_bts() {
  long debugctlmsr;
  intel_pmu_enable_bts___trans_tmp_1 = ({
    asm(""
        : "=c"(intel_pmu_enable_bts___ecx), "=a"(intel_pmu_enable_bts___eax));
    intel_pmu_enable_bts___eax;
  });
  debugctlmsr = intel_pmu_enable_bts___trans_tmp_1;
  debugctlmsr |= 6;
  if (intel_pmu_enable_bts_config)
    debugctlmsr |= 9;
  if (intel_pmu_enable_bts_config & 16)
    debugctlmsr |= 1;
  unsigned low = debugctlmsr;
  asm(".pushsection .discard.retpoline_safe\n\t"
      ".popsection\n"
      :
      : "S"(low));
}

$ clang -O2 -g -c -o /dev/null ds.i

A reduced reproducer for the second:

$ cat fork.i
typedef struct {
  int counter
} atomic_t;
enum { MM_SHMEMPAGES };
dup_mm_err;
atomic_long_read(atomic_t *v) { *(volatile *)v; }
struct mm_struct {
  struct {
    int binfmt
  };
} get_mm_counter(struct mm_struct *mm, int member) {
  atomic_long_read(&mm[member]);
}
dup_mm() {
  struct mm_struct *mm = kmem_cache_alloc(0);
  if (!mm)
    goto fail_nomem;
  if (dup_mm_err)
    goto free_pt;
  get_mm_counter(mm, MM_SHMEMPAGES);
  return mm;
free_pt:
  mm->binfmt = 0;
fail_nomem:
  return 0;
}

$ clang --target=arm-linux-gnueabi -march=armv6k -O2 -g -c -o /dev/null fork.i

The full preprocessed files are available here:

https://github.com/nathanchance/creduce-files/tree/fcef93c38903db773a8a46840b5e7b43a4444e85/791930d74087b8ae8901172861a0fd21a211e436-arm

https://github.com/nathanchance/creduce-files/tree/fcef93c38903db773a8a46840b5e7b43a4444e85/791930d74087b8ae8901172861a0fd21a211e436-x86

Thanks for the report @nathanchance, I'm putting together a fix now. The first error looks to be quite straightforward (the error is contained to a single small function), and I'm currently investigating the latter - if it seems sufficiently complicated I'll revert pending a fix, otherwise I'll submit a fix today and get it merged in shortly afterwards.

Fixes are up for review at D101523 and D101540; both fixes are quite small and so shouldn't be held up too long in review, but if the fix is needed urgently you can either apply those patches directly while awaiting their arrival in the main branch, or they can potentially be commited prior to finishing review - this isn't preferred, but is an option for sufficiently simple changes.

@StephenTozer what's the status of the two fixes? Can you chase those please? You shouldn't be leaving breaking changes in for >24hrs please.

Bumping; I just hit this again trying to debug an unrelated case: https://github.com/ClangBuiltLinux/linux/issues/1365#issuecomment-830388033. If this can't be fixed forward by EOD, I'm reverting it so we don't go into the weekend with this.

nickdesaulniers reopened this revision.Apr 30 2021, 4:47 PM

Reverted in https://reviews.llvm.org/rGb11e4c990771541e440861f017afea7b4ba162f4 as per https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy. I apologize for extra effort and delays in this feature that causes, but we are more than willing to go out of our way to help you test a revised version of this patch. Perhaps it would be appropriate at this point to squash D101523 and D101540 into this?

This revision is now accepted and ready to land.Apr 30 2021, 4:47 PM
nickdesaulniers requested changes to this revision.Apr 30 2021, 4:48 PM
This revision now requires changes to proceed.Apr 30 2021, 4:48 PM

b11e4c990771541e440861f017afea7b4ba162f4 only reverted D101373, which was a follow-up fix to this one. I reverted this patch in 4397b7095d640f9b9426c4d0135e999c5a1de1c5.

So this patch should be recommitted with D101373, D101523, and D101540 squashed in it seems. I am free to test a new revision against the kernel on Monday.

@StephenTozer what's the status of the two fixes? Can you chase those please? You shouldn't be leaving breaking changes in for >24hrs please.

Apologies for not reverting sooner and leaving you to take care of it; the fixes are still under review, when they complete I'll reapply the whole stack.

sbc100 added a subscriber: sbc100.May 21 2021, 1:03 PM

After the third re-land of this patch we are seeing a crash in the emscripten compiler: https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket.appspot.com/8846604336499720256/+/steps/Emscripten_testsuite__upstream__other_/0/stdout

cache:INFO: generating system library: sysroot/lib/wasm32-emscripten/libbullet.a... (this will be cached in "/b/s/w/ir/k/install/emscripten/cache/sysroot/lib/wasm32-emscripten/libbullet.a" for subsequent builds)
root:INFO: building port: bullet
['--bind', '-O2', '-s', 'EMBIND_STD_STRING_IS_UTF8=0']
clang++: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp:423: virtual bool (anonymous namespace)::WebAssemblyExplicitLocals::runOnMachineFunction(llvm::MachineFunction &): Assertion `(!MO.isReg() || MRI.use_empty(MO.getReg()) || MFI.isVRegStackified(MO.getReg())) && "WebAssemblyExplicitLocals failed to stackify a register operand"' failed.
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.	Program arguments: /b/s/w/ir/k/install/bin/clang++ -target wasm32-unknown-emscripten -DEMSCRIPTEN -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -D__EMSCRIPTEN_major__=2 -D__EMSCRIPTEN_minor__=0 -D__EMSCRIPTEN_tiny__=22 -D_LIBCPP_ABI_VERSION=2 -Dunix -D__unix -D__unix__ -Werror=implicit-function-declaration -Xclang -iwithsysroot/include/SDL --sysroot=/b/s/w/ir/k/install/emscripten/cache/sysroot -Xclang -iwithsysroot/include/compat -g -c -O2 -w -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/vectormath/scalar -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/vectormath/sse -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletCollision/CollisionShapes -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletCollision/NarrowPhaseCollision -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletCollision/BroadphaseCollision -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletCollision/Gimpact -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletCollision/CollisionDispatch -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/Dynamics -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/Vehicle -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/Character -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/MLCPSolvers -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/Featherstone -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/ConstraintSolver -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/MiniCL/MiniCLTask -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/vectormath -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletCollision -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/LinearMath -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletSoftBody -I/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/MiniCL /b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/ConstraintSolver/btSequentialImpulseConstraintSolver.cpp -o /b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/ConstraintSolver/btSequentialImpulseConstraintSolver.cpp.o
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module '/b/s/w/ir/k/install/emscripten/cache/ports-builds/bullet/bullet/src/BulletDynamics/ConstraintSolver/btSequentialImpulseConstraintSolver.cpp'.
4.	Running pass 'WebAssembly Explicit Locals' on function '@_ZN35btSequentialImpulseConstraintSolver28solveGroupCacheFriendlySetupEPP17btCollisionObjectiPP20btPersistentManifoldiPP17btTypedConstraintiRK19btContactSolverInfoP12btIDebugDraw'
 #0 0x00007f98e689efa3 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x18d1fa3)
 #1 0x00007f98e689cd9e llvm::sys::RunSignalHandlers() (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x18cfd9e)
 #2 0x00007f98e689e31d llvm::sys::CleanupOnSignal(unsigned long) (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x18d131d)
 #3 0x00007f98e67d22d3 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) CrashRecoveryContext.cpp:0:0
 #4 0x00007f98e67d243e CrashRecoverySignalHandler(int) CrashRecoveryContext.cpp:0:0
 #5 0x00007f98e4dc0980 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12980)
 #6 0x00007f98e0a02fb7 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3efb7)
 #7 0x00007f98e0a04921 abort (/lib/x86_64-linux-gnu/libc.so.6+0x40921)
 #8 0x00007f98e09f448a (/lib/x86_64-linux-gnu/libc.so.6+0x3048a)
 #9 0x00007f98e09f4502 (/lib/x86_64-linux-gnu/libc.so.6+0x30502)
#10 0x00007f98e892bb50 (anonymous namespace)::WebAssemblyExplicitLocals::runOnMachineFunction(llvm::MachineFunction&) WebAssemblyExplicitLocals.cpp:0:0
#11 0x00007f98e6cc5ced llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x1cf8ced)
#12 0x00007f98e6a194b8 llvm::FPPassManager::runOnFunction(llvm::Function&) (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x1a4c4b8)
#13 0x00007f98e6a21941 llvm::FPPassManager::runOnModule(llvm::Module&) (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x1a54941)
#14 0x00007f98e6a19fcb llvm::legacy::PassManagerImpl::run(llvm::Module&) (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x1a4cfcb)
#15 0x00007f98e39cf5b6 (anonymous namespace)::EmitAssemblyHelper::EmitAssemblyWithNewPassManager(clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) BackendUtil.cpp:0:0
#16 0x00007f98e39c9d33 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::StringRef, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x265ed33)
#17 0x00007f98e3cf3e80 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) CodeGenAction.cpp:0:0
#18 0x00007f98e29e46e4 clang::ParseAST(clang::Sema&, bool, bool) (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x16796e4)
#19 0x00007f98e42e9220 clang::FrontendAction::Execute() (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x2f7e220)
#20 0x00007f98e425fe7f clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x2ef4e7f)
#21 0x00007f98e436821c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x2ffd21c)
#22 0x00000000002145b2 cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/b/s/w/ir/k/install/bin/clang+++0x2145b2)
#23 0x000000000021213d ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) driver.cpp:0:0
#24 0x00007f98e3f37ca2 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const::$_1>(long) Job.cpp:0:0
#25 0x00007f98e67d21e7 llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) (/b/s/w/ir/k/install/bin/../lib/libLLVM-13git.so+0x18051e7)
#26 0x00007f98e3f377f7 clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, bool*) const (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x2bcc7f7)
#27 0x00007f98e3f02ce8 clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x2b97ce8)
#28 0x00007f98e3f02fb7 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) const (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x2b97fb7)
#29 0x00007f98e3f1d091 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*> >&) (/b/s/w/ir/k/install/bin/../lib/libclang-cpp.so.13git+0x2bb2091)
#30 0x0000000000211a06 main (/b/s/w/ir/k/install/bin/clang+++0x211a06)
#31 0x00007f98e09e5bf7 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf7)
#32 0x000000000020ed6a _start (/b/s/w/ir/k/install/bin/clang+++0x20ed6a)
clang-13: error: clang frontend command failed with exit code 134 (use -v to see invocation)
clang version 13.0.0 (/b/s/w/ir/cache/git/chromium.googlesource.com-external-github.com-llvm-llvm--project 95612afc1d69ff470943b10210bb902fa14fc4e8)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /b/s/w/ir/k/install/bin
clang-13: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-13: note: diagnostic msg: /b/s/w/ir/tmp/t/btSequentialImpulseConstraintSolver-d507ac.cpp
clang-13: note: diagnostic msg: /b/s/w/ir/tmp/t/btSequentialImpulseConstraintSolver-d507ac.sh
clang-13: note: diagnostic msg: 

********************

I went back and testing this with the intial landing, and with the 1st and 2nd re-landing and none of those broke us.. Only the 3rd re-landing.

Thanks for the report -- we're out of working hours in the UK timezone and I can't revert myself, if you could revert this for us, please do.

Thanks for the report -- we're out of working hours in the UK timezone and I can't revert myself, if you could revert this for us, please do.

We are investigating now. I looks like this assert only fires in combination with WebAssemlby change that was landed between the 2nd and 3rd re-landing: https://reviews.llvm.org/D102589. I think we will try to fix forward if we can and if that fails revert either or the other.

wenlei added a subscriber: wenlei.May 25 2021, 10:18 PM

We're seeing a pathological case with 36ec97f76ac0d8be76fb16ac521f55126766267d (3rd Reapply "[DebugInfo] Use variadic debug values to salvage BinOps and GEP instrs with non-const operands).

Compilation of certain cpp file slowed down from ~17s to 10+ hours. It seems stuck in inliner but actually it's spending huge amount of time trying to replace all uses of function call with the return value for each inlined call. This is because the calls are being used in 10K+ of DIArgList metadata. And for each DIArgList, we need to go through each Arg in order to replace any occurrence of the old value, and in this case, we often have hundreds of Arg for each DIArgList. All of that is then multiplied by hundreds of inline site ...

Those huge DIArgList starts to appear after InstrCombine. I haven't tried to verify whether the generated DIArgList and the debug intrinsic is legit, but wondering if this is potentially a known issue? This is affecting builds for several of our large workloads.

Example of a problematic, huge DIArgList, and we have many of those:

call void @llvm.dbg.value(metadata !DIArgList(i64 %256, i64 %2379, i64 %2375, i64 %2371, i64 %2367, i64 %2363, i64 %2358, i64 %2350, i64 %2346, i64 %2342, i64 %2338, i64 %2334, i64 %2330, i64 %2326, i64 %2322, i64 %2318, i64 %2314, i64 %2310, i64 %2305, i64 %2296, i64 %2287, i64 %2279, i64 %2275, i64 %2271, i64 %2267, i64 %2263, i64 %2259, i64 %2254, i64 %2245, i64 %2231, i64 %2218, i64 %2214, i64 %2210, i64 %2205, i64 %2196, i64 %2187, i64 %2179, i64 %2174, i64 %2165, i64 %2157, i64 %2152, i64 %2138, i64 %2125, i64 %2121, i64 %2116, i64 %2108, i64 %2104, i64 %2100, i64 %2096, i64 %2092, i64 %2088, i64 %2084, i64 %2080, i64 %2076, i64 %2072, i64 %2067, i64 %2059, i64 %2055, i64 %2050, i64 %2037, i64 %2033, i64 %2029, i64 %2025, i64 %2021, i64 %2016, i64 %2003, i64 %1998, i64 %1989, i64 %1976, i64 %1972, i64 %1968, i64 %1964, i64 %1960, i64 %1956, i64 %1952, i64 %1948, i64 %1944, i64 %1940, i64 %1935, i64 %1921, i64 %1907, i64 %1899, i64 %1895, i64 %1891, i64 %1887, i64 %1883, i64 %1879, i64 %1875, i64 %1871, i64 %1866, i64 %1853, i64 %1849, i64 %1845, i64 %1841, i64 %1837, i64 %1833, i64 %1829, i64 %1825, i64 %1821, i64 %1816, i64 %1802, i64 %1789, i64 %1785, i64 %1781, i64 %1776, i64 %1763, i64 %1759, i64 %1755, i64 %1751, i64 %1746, i64 %1737, i64 %1728, i64 %1719, i64 %1706, i64 %1701, i64 %1693, i64 %1688, i64 %1676, i64 %1672, i64 %1668, i64 %1664, i64 %1660, i64 %1656, i64 %1652, i64 %1647, i64 %1633, i64 %1620, i64 %1615, i64 %1607, i64 %1603, i64 %1599, i64 %1595, i64 %1591, i64 %1587, i64 %1583, i64 %1579, i64 %1575, i64 %1571, i64 %1566, i64 %1553, i64 %1549, i64 %1545, i64 %1541, i64 %1537, i64 %1532, i64 %1519, i64 %1515, i64 %1511, i64 %1507, i64 %1503, i64 %1498, i64 %1484, i64 %1475, i64 %1462, i64 %1458, i64 %1454, i64 %1450, i64 %1446, i64 %1442, i64 %1438, i64 %1434, i64 %1429, i64 %1416, i64 %1412, i64 %1408, i64 %1404, i64 %1400, i64 %1396, i64 %1392, i64 %1388, i64 %1383, i64 %1374, i64 %1365, i64 %1352, i64 %1348, i64 %1344, i64 %1340, i64 %1336, i64 %1332, i64 %1328, i64 %1324, i64 %1320, i64 %1316, i64 %1311, i64 %1298, i64 %1294, i64 %1290, i64 %1286, i64 %1282, i64 %1278, i64 %1274, i64 %1270, i64 %1266, i64 %1262, i64 %1258, i64 %1253, i64 %1240, i64 %1235, i64 %1226, i64 %1218, i64 %1213, i64 %1205, i64 %1201, i64 %1197, i64 %1193, i64 %1189, i64 %1185, i64 %1181, i64 %1177, i64 %1172, i64 %1163, i64 %1150, i64 %1146, i64 %1142, i64 %1138, i64 %1134, i64 %1130, i64 %1125, i64 %1111, i64 %1098, i64 %1094, i64 %1090, i64 %1086, i64 %1081, i64 %1068, i64 %1064, i64 %1060, i64 %1055, i64 %1046, i64 %1038, i64 %1034, i64 %1029, i64 %1021, i64 %1017, i64 %1012, i64 %999, i64 %990, i64 %982, i64 %978, i64 %973, i64 %959, i64 %947, i64 %942, i64 %934, i64 %930, i64 %925, i64 %916, i64 %908, i64 %904, i64 %899, i64 %882, i64 %877, i64 %869, i64 %865, i64 %860, i64 %852, i64 %847, i64 %838, i64 %826, i64 %822, i64 %818, i64 %813, i64 %800, i64 %796, i64 %792, i64 %787, i64 %778, i64 %766, i64 %762, i64 %758, i64 %754, i64 %749, i64 %736, i64 %724, i64 %719, i64 %707, i64 %703, i64 %698, i64 %684, i64 %672, i64 %667, i64 %654, i64 %649, i64 %636, i64 %632, i64 %628, i64 %623, i64 %610, i64 %606, i64 %602, i64 %597, i64 %589, i64 %585, i64 %580, i64 %562, i64 %544, i64 %535, i64 %521, i64 %513, i64 %509, i64 %505, i64 %500, i64 %487, i64 %482, i64 %474, i64 %470, i64 %466, i64 %462, i64 %458, i64 %454, i64 %450, i64 %446, i64 %442, i64 %438, i64 %433, i64 %420, i64 %415, i64 %406, i64 %398, i64 %394, i64 %390, i64 %386, i64 %382, i64 %378, i64 %373, i64 %360, i64 %356, i64 %351, i64 %338, i64 %333, i64 %320, i64 %316, i64 %312, i64 %308, i64 %304, i64 %300, i64 %296, i64 %292, i64 %288, i64 %284, i64 %280, i64 %276, i64 %272, i64 %268, i64 %264, i64 %260), metadata !135223, metadata !DIExpression(DW_OP_LLVM_arg, 0, DW_OP_LLVM_arg, 345, DW_OP_plus, DW_OP_LLVM_arg, 344, DW_OP_plus, DW_OP_LLVM_arg, 343, DW_OP_plus, DW_OP_LLVM_arg, 342, DW_OP_plus, DW_OP_LLVM_arg, 341, DW_OP_plus, DW_OP_LLVM_arg, 340, DW_OP_plus, DW_OP_LLVM_arg, 339, DW_OP_plus, DW_OP_LLVM_arg, 338, DW_OP_plus, DW_OP_LLVM_arg, 337, DW_OP_plus, DW_OP_LLVM_arg, 336, DW_OP_plus, DW_OP_LLVM_arg, 335, DW_OP_plus, DW_OP_LLVM_arg, 334, DW_OP_plus, DW_OP_LLVM_arg, 333, DW_OP_plus, DW_OP_LLVM_arg, 332, DW_OP_plus, DW_OP_LLVM_arg, 331, DW_OP_plus, DW_OP_LLVM_arg, 330, DW_OP_plus, DW_OP_LLVM_arg, 329, DW_OP_plus, DW_OP_LLVM_arg, 328, DW_OP_plus, DW_OP_LLVM_arg, 327, DW_OP_plus, DW_OP_LLVM_arg, 326, DW_OP_plus, DW_OP_LLVM_arg, 325, DW_OP_plus, DW_OP_LLVM_arg, 324, DW_OP_plus, DW_OP_LLVM_arg, 323, DW_OP_plus, DW_OP_LLVM_arg, 322, DW_OP_plus, DW_OP_LLVM_arg, 321, DW_OP_plus, DW_OP_LLVM_arg, 320, DW_OP_plus, DW_OP_LLVM_arg, 319, DW_OP_plus, DW_OP_LLVM_arg, 318, DW_OP_plus, DW_OP_LLVM_arg, 317, DW_OP_plus, DW_OP_LLVM_arg, 316, DW_OP_plus, DW_OP_LLVM_arg, 315, DW_OP_plus, DW_OP_LLVM_arg, 314, DW_OP_plus, DW_OP_LLVM_arg, 313, DW_OP_plus, DW_OP_LLVM_arg, 312, DW_OP_plus, DW_OP_LLVM_arg, 311, DW_OP_plus, DW_OP_LLVM_arg, 310, DW_OP_plus, DW_OP_LLVM_arg, 309, DW_OP_plus, DW_OP_LLVM_arg, 308, DW_OP_plus, DW_OP_LLVM_arg, 307, DW_OP_plus, DW_OP_LLVM_arg, 306, DW_OP_plus, DW_OP_LLVM_arg, 305, DW_OP_plus, DW_OP_LLVM_arg, 304, DW_OP_plus, DW_OP_LLVM_arg, 303, DW_OP_plus, DW_OP_LLVM_arg, 302, DW_OP_plus, DW_OP_LLVM_arg, 301, DW_OP_plus, DW_OP_LLVM_arg, 300, DW_OP_plus, DW_OP_LLVM_arg, 299, DW_OP_plus, DW_OP_LLVM_arg, 298, DW_OP_plus, DW_OP_LLVM_arg, 297, DW_OP_plus, DW_OP_LLVM_arg, 296, DW_OP_plus, DW_OP_LLVM_arg, 295, DW_OP_plus, DW_OP_LLVM_arg, 294, DW_OP_plus, DW_OP_LLVM_arg, 293, DW_OP_plus, DW_OP_LLVM_arg, 292, DW_OP_plus, DW_OP_LLVM_arg, 291, DW_OP_plus, DW_OP_LLVM_arg, 290, DW_OP_plus, DW_OP_LLVM_arg, 289, DW_OP_plus, DW_OP_LLVM_arg, 288, DW_OP_plus, DW_OP_LLVM_arg, 287, DW_OP_plus, DW_OP_LLVM_arg, 286, DW_OP_plus, DW_OP_LLVM_arg, 285, DW_OP_plus, DW_OP_LLVM_arg, 284, DW_OP_plus, DW_OP_LLVM_arg, 283, DW_OP_plus, DW_OP_LLVM_arg, 282, DW_OP_plus, DW_OP_LLVM_arg, 281, DW_OP_plus, DW_OP_LLVM_arg, 280, DW_OP_plus, DW_OP_LLVM_arg, 279, DW_OP_plus, DW_OP_LLVM_arg, 278, DW_OP_plus, DW_OP_LLVM_arg, 277, DW_OP_plus, DW_OP_LLVM_arg, 276, DW_OP_plus, DW_OP_LLVM_arg, 275, DW_OP_plus, DW_OP_LLVM_arg, 274, DW_OP_plus, DW_OP_LLVM_arg, 273, DW_OP_plus, DW_OP_LLVM_arg, 272, DW_OP_plus, DW_OP_LLVM_arg, 271, DW_OP_plus, DW_OP_LLVM_arg, 270, DW_OP_plus, DW_OP_LLVM_arg, 269, DW_OP_plus, DW_OP_LLVM_arg, 268, DW_OP_plus, DW_OP_LLVM_arg, 267, DW_OP_plus, DW_OP_LLVM_arg, 266, DW_OP_plus, DW_OP_LLVM_arg, 265, DW_OP_plus, DW_OP_LLVM_arg, 264, DW_OP_plus, DW_OP_LLVM_arg, 263, DW_OP_plus, DW_OP_LLVM_arg, 262, DW_OP_plus, DW_OP_LLVM_arg, 261, DW_OP_plus, DW_OP_LLVM_arg, 260, DW_OP_plus, DW_OP_LLVM_arg, 259, DW_OP_plus, DW_OP_LLVM_arg, 258, DW_OP_plus, DW_OP_LLVM_arg, 257, DW_OP_plus, DW_OP_LLVM_arg, 256, DW_OP_plus, DW_OP_LLVM_arg, 255, DW_OP_plus, DW_OP_LLVM_arg, 254, DW_OP_plus, DW_OP_LLVM_arg, 253, DW_OP_plus, DW_OP_LLVM_arg, 252, DW_OP_plus, DW_OP_LLVM_arg, 251, DW_OP_plus, DW_OP_LLVM_arg, 250, DW_OP_plus, DW_OP_LLVM_arg, 249, DW_OP_plus, DW_OP_LLVM_arg, 248, DW_OP_plus, DW_OP_LLVM_arg, 247, DW_OP_plus, DW_OP_LLVM_arg, 246, DW_OP_plus, DW_OP_LLVM_arg, 245, DW_OP_plus, DW_OP_LLVM_arg, 244, DW_OP_plus, DW_OP_LLVM_arg, 243, DW_OP_plus, DW_OP_LLVM_arg, 242, DW_OP_plus, DW_OP_LLVM_arg, 241, DW_OP_plus, DW_OP_LLVM_arg, 240, DW_OP_plus, DW_OP_LLVM_arg, 239, DW_OP_plus, DW_OP_LLVM_arg, 238, DW_OP_plus, DW_OP_LLVM_arg, 237, DW_OP_plus, DW_OP_LLVM_arg, 236, DW_OP_plus, DW_OP_LLVM_arg, 235, DW_OP_plus, DW_OP_LLVM_arg, 234, DW_OP_plus, DW_OP_LLVM_arg, 233, DW_OP_plus, DW_OP_LLVM_arg, 232, DW_OP_plus, DW_OP_LLVM_arg, 231, DW_OP_plus, DW_OP_LLVM_arg, 230, DW_OP_plus, DW_OP_LLVM_arg, 229, DW_OP_plus, DW_OP_LLVM_arg, 228, DW_OP_plus, DW_OP_LLVM_arg, 227, DW_OP_plus, DW_OP_LLVM_arg, 226, DW_OP_plus, DW_OP_LLVM_arg, 225, DW_OP_plus, DW_OP_LLVM_arg, 224, DW_OP_plus, DW_OP_LLVM_arg, 223, DW_OP_plus, DW_OP_LLVM_arg, 222, DW_OP_plus, DW_OP_LLVM_arg, 221, DW_OP_plus, DW_OP_LLVM_arg, 220, DW_OP_plus, DW_OP_LLVM_arg, 219, DW_OP_plus, DW_OP_LLVM_arg, 218, DW_OP_plus, DW_OP_LLVM_arg, 217, DW_OP_plus, DW_OP_LLVM_arg, 216, DW_OP_plus, DW_OP_LLVM_arg, 215, DW_OP_plus, DW_OP_LLVM_arg, 214, DW_OP_plus, DW_OP_LLVM_arg, 213, DW_OP_plus, DW_OP_LLVM_arg, 212, DW_OP_plus, DW_OP_LLVM_arg, 211, DW_OP_plus, DW_OP_LLVM_arg, 210, DW_OP_plus, DW_OP_LLVM_arg, 209, DW_OP_plus, DW_OP_LLVM_arg, 208, DW_OP_plus, DW_OP_LLVM_arg, 207, DW_OP_plus, DW_OP_LLVM_arg, 206, DW_OP_plus, DW_OP_LLVM_arg, 205, DW_OP_plus, DW_OP_LLVM_arg, 204, DW_OP_plus, DW_OP_LLVM_arg, 203, DW_OP_plus, DW_OP_LLVM_arg, 202, DW_OP_plus, DW_OP_LLVM_arg, 201, DW_OP_plus, DW_OP_LLVM_arg, 200, DW_OP_plus, DW_OP_LLVM_arg, 199, DW_OP_plus, DW_OP_LLVM_arg, 198, DW_OP_plus, DW_OP_LLVM_arg, 197, DW_OP_plus, DW_OP_LLVM_arg, 196, DW_OP_plus, DW_OP_LLVM_arg, 195, DW_OP_plus, DW_OP_LLVM_arg, 194, DW_OP_plus, DW_OP_LLVM_arg, 193, DW_OP_plus, DW_OP_LLVM_arg, 192, DW_OP_plus, DW_OP_LLVM_arg, 191, DW_OP_plus, DW_OP_LLVM_arg, 190, DW_OP_plus, DW_OP_LLVM_arg, 189, DW_OP_plus, DW_OP_LLVM_arg, 188, DW_OP_plus, DW_OP_LLVM_arg, 187, DW_OP_plus, DW_OP_LLVM_arg, 186, DW_OP_plus, DW_OP_LLVM_arg, 185, DW_OP_plus, DW_OP_LLVM_arg, 184, DW_OP_plus, DW_OP_LLVM_arg, 183, DW_OP_plus, DW_OP_LLVM_arg, 182, DW_OP_plus, DW_OP_LLVM_arg, 181, DW_OP_plus, DW_OP_LLVM_arg, 180, DW_OP_plus, DW_OP_LLVM_arg, 179, DW_OP_plus, DW_OP_LLVM_arg, 178, DW_OP_plus, DW_OP_LLVM_arg, 177, DW_OP_plus, DW_OP_LLVM_arg, 176, DW_OP_plus, DW_OP_LLVM_arg, 175, DW_OP_plus, DW_OP_LLVM_arg, 174, DW_OP_plus, DW_OP_LLVM_arg, 173, DW_OP_plus, DW_OP_LLVM_arg, 172, DW_OP_plus, DW_OP_LLVM_arg, 171, DW_OP_plus, DW_OP_LLVM_arg, 170, DW_OP_plus, DW_OP_LLVM_arg, 169, DW_OP_plus, DW_OP_LLVM_arg, 168, DW_OP_plus, DW_OP_LLVM_arg, 167, DW_OP_plus, DW_OP_LLVM_arg, 166, DW_OP_plus, DW_OP_LLVM_arg, 165, DW_OP_plus, DW_OP_LLVM_arg, 164, DW_OP_plus, DW_OP_LLVM_arg, 163, DW_OP_plus, DW_OP_LLVM_arg, 162, DW_OP_plus, DW_OP_LLVM_arg, 161, DW_OP_plus, DW_OP_LLVM_arg, 160, DW_OP_plus, DW_OP_LLVM_arg, 159, DW_OP_plus, DW_OP_LLVM_arg, 158, DW_OP_plus, DW_OP_LLVM_arg, 157, DW_OP_plus, DW_OP_LLVM_arg, 156, DW_OP_plus, DW_OP_LLVM_arg, 155, DW_OP_plus, DW_OP_LLVM_arg, 154, DW_OP_plus, DW_OP_LLVM_arg, 153, DW_OP_plus, DW_OP_LLVM_arg, 152, DW_OP_plus, DW_OP_LLVM_arg, 151, DW_OP_plus, DW_OP_LLVM_arg, 150, DW_OP_plus, DW_OP_LLVM_arg, 149, DW_OP_plus, DW_OP_LLVM_arg, 148, DW_OP_plus, DW_OP_LLVM_arg, 147, DW_OP_plus, DW_OP_LLVM_arg, 146, DW_OP_plus, DW_OP_LLVM_arg, 145, DW_OP_plus, DW_OP_LLVM_arg, 144, DW_OP_plus, DW_OP_LLVM_arg, 143, DW_OP_plus, DW_OP_LLVM_arg, 142, DW_OP_plus, DW_OP_LLVM_arg, 141, DW_OP_plus, DW_OP_LLVM_arg, 140, DW_OP_plus, DW_OP_LLVM_arg, 139, DW_OP_plus, DW_OP_LLVM_arg, 138, DW_OP_plus, DW_OP_LLVM_arg, 137, DW_OP_plus, DW_OP_LLVM_arg, 136, DW_OP_plus, DW_OP_LLVM_arg, 135, DW_OP_plus, DW_OP_LLVM_arg, 134, DW_OP_plus, DW_OP_LLVM_arg, 133, DW_OP_plus, DW_OP_LLVM_arg, 132, DW_OP_plus, DW_OP_LLVM_arg, 131, DW_OP_plus, DW_OP_LLVM_arg, 130, DW_OP_plus, DW_OP_LLVM_arg, 129, DW_OP_plus, DW_OP_LLVM_arg, 128, DW_OP_plus, DW_OP_LLVM_arg, 127, DW_OP_plus, DW_OP_LLVM_arg, 126, DW_OP_plus, DW_OP_LLVM_arg, 125, DW_OP_plus, DW_OP_LLVM_arg, 124, DW_OP_plus, DW_OP_LLVM_arg, 123, DW_OP_plus, DW_OP_LLVM_arg, 122, DW_OP_plus, DW_OP_LLVM_arg, 121, DW_OP_plus, DW_OP_LLVM_arg, 120, DW_OP_plus, DW_OP_LLVM_arg, 119, DW_OP_plus, DW_OP_LLVM_arg, 118, DW_OP_plus, DW_OP_LLVM_arg, 117, DW_OP_plus, DW_OP_LLVM_arg, 116, DW_OP_plus, DW_OP_LLVM_arg, 115, DW_OP_plus, DW_OP_LLVM_arg, 114, DW_OP_plus, DW_OP_LLVM_arg, 113, DW_OP_plus, DW_OP_LLVM_arg, 112, DW_OP_plus, DW_OP_LLVM_arg, 111, DW_OP_plus, DW_OP_LLVM_arg, 110, DW_OP_plus, DW_OP_LLVM_arg, 109, DW_OP_plus, DW_OP_LLVM_arg, 108, DW_OP_plus, DW_OP_LLVM_arg, 107, DW_OP_plus, DW_OP_LLVM_arg, 106, DW_OP_plus, DW_OP_LLVM_arg, 105, DW_OP_plus, DW_OP_LLVM_arg, 104, DW_OP_plus, DW_OP_LLVM_arg, 103, DW_OP_plus, DW_OP_LLVM_arg, 102, DW_OP_plus, DW_OP_LLVM_arg, 101, DW_OP_plus, DW_OP_LLVM_arg, 100, DW_OP_plus, DW_OP_LLVM_arg, 99, DW_OP_plus, DW_OP_LLVM_arg, 98, DW_OP_plus, DW_OP_LLVM_arg, 97, DW_OP_plus, DW_OP_LLVM_arg, 96, DW_OP_plus, DW_OP_LLVM_arg, 95, DW_OP_plus, DW_OP_LLVM_arg, 94, DW_OP_plus, DW_OP_LLVM_arg, 93, DW_OP_plus, DW_OP_LLVM_arg, 92, DW_OP_plus, DW_OP_LLVM_arg, 91, DW_OP_plus, DW_OP_LLVM_arg, 90, DW_OP_plus, DW_OP_LLVM_arg, 89, DW_OP_plus, DW_OP_LLVM_arg, 88, DW_OP_plus, DW_OP_LLVM_arg, 87, DW_OP_plus, DW_OP_LLVM_arg, 86, DW_OP_plus, DW_OP_LLVM_arg, 85, DW_OP_plus, DW_OP_LLVM_arg, 84, DW_OP_plus, DW_OP_LLVM_arg, 83, DW_OP_plus, DW_OP_LLVM_arg, 82, DW_OP_plus, DW_OP_LLVM_arg, 81, DW_OP_plus, DW_OP_LLVM_arg, 80, DW_OP_plus, DW_OP_LLVM_arg, 79, DW_OP_plus, DW_OP_LLVM_arg, 78, DW_OP_plus, DW_OP_LLVM_arg, 77, DW_OP_plus, DW_OP_LLVM_arg, 76, DW_OP_plus, DW_OP_LLVM_arg, 75, DW_OP_plus, DW_OP_LLVM_arg, 74, DW_OP_plus, DW_OP_LLVM_arg, 73, DW_OP_plus, DW_OP_LLVM_arg, 72, DW_OP_plus, DW_OP_LLVM_arg, 71, DW_OP_plus, DW_OP_LLVM_arg, 70, DW_OP_plus, DW_OP_LLVM_arg, 69, DW_OP_plus, DW_OP_LLVM_arg, 68, DW_OP_plus, DW_OP_LLVM_arg, 67, DW_OP_plus, DW_OP_LLVM_arg, 66, DW_OP_plus, DW_OP_LLVM_arg, 65, DW_OP_plus, DW_OP_LLVM_arg, 64, DW_OP_plus, DW_OP_LLVM_arg, 63, DW_OP_plus, DW_OP_LLVM_arg, 62, DW_OP_plus, DW_OP_LLVM_arg, 61, DW_OP_plus, DW_OP_LLVM_arg, 60, DW_OP_plus, DW_OP_LLVM_arg, 59, DW_OP_plus, DW_OP_LLVM_arg, 58, DW_OP_plus, DW_OP_LLVM_arg, 57, DW_OP_plus, DW_OP_LLVM_arg, 56, DW_OP_plus, DW_OP_LLVM_arg, 55, DW_OP_plus, DW_OP_LLVM_arg, 54, DW_OP_plus, DW_OP_LLVM_arg, 53, DW_OP_plus, DW_OP_LLVM_arg, 52, DW_OP_plus, DW_OP_LLVM_arg, 51, DW_OP_plus, DW_OP_LLVM_arg, 50, DW_OP_plus, DW_OP_LLVM_arg, 49, DW_OP_plus, DW_OP_LLVM_arg, 48, DW_OP_plus, DW_OP_LLVM_arg, 47, DW_OP_plus, DW_OP_LLVM_arg, 46, DW_OP_plus, DW_OP_LLVM_arg, 45, DW_OP_plus, DW_OP_LLVM_arg, 44, DW_OP_plus, DW_OP_LLVM_arg, 43, DW_OP_plus, DW_OP_LLVM_arg, 42, DW_OP_plus, DW_OP_LLVM_arg, 41, DW_OP_plus, DW_OP_LLVM_arg, 40, DW_OP_plus, DW_OP_LLVM_arg, 39, DW_OP_plus, DW_OP_LLVM_arg, 38, DW_OP_plus, DW_OP_LLVM_arg, 37, DW_OP_plus, DW_OP_LLVM_arg, 36, DW_OP_plus, DW_OP_LLVM_arg, 35, DW_OP_plus, DW_OP_LLVM_arg, 34, DW_OP_plus, DW_OP_LLVM_arg, 33, DW_OP_plus, DW_OP_LLVM_arg, 32, DW_OP_plus, DW_OP_LLVM_arg, 31, DW_OP_plus, DW_OP_LLVM_arg, 30, DW_OP_plus, DW_OP_LLVM_arg, 29, DW_OP_plus, DW_OP_LLVM_arg, 28, DW_OP_plus, DW_OP_LLVM_arg, 27, DW_OP_plus, DW_OP_LLVM_arg, 26, DW_OP_plus, DW_OP_LLVM_arg, 25, DW_OP_plus, DW_OP_LLVM_arg, 24, DW_OP_plus, DW_OP_LLVM_arg, 23, DW_OP_plus, DW_OP_LLVM_arg, 22, DW_OP_plus, DW_OP_LLVM_arg, 21, DW_OP_plus, DW_OP_LLVM_arg, 20, DW_OP_plus, DW_OP_LLVM_arg, 19, DW_OP_plus, DW_OP_LLVM_arg, 18, DW_OP_plus, DW_OP_LLVM_arg, 17, DW_OP_plus, DW_OP_LLVM_arg, 16, DW_OP_plus, DW_OP_LLVM_arg, 15, DW_OP_plus, DW_OP_LLVM_arg, 14, DW_OP_plus, DW_OP_LLVM_arg, 13, DW_OP_plus, DW_OP_LLVM_arg, 12, DW_OP_plus, DW_OP_LLVM_arg, 11, DW_OP_plus, DW_OP_LLVM_arg, 10, DW_OP_plus, DW_OP_LLVM_arg, 9, DW_OP_plus, DW_OP_LLVM_arg, 8, DW_OP_plus, DW_OP_LLVM_arg, 7, DW_OP_plus, DW_OP_LLVM_arg, 6, DW_OP_plus, DW_OP_LLVM_arg, 5, DW_OP_plus, DW_OP_LLVM_arg, 4, DW_OP_plus, DW_OP_LLVM_arg, 3, DW_OP_plus, DW_OP_LLVM_arg, 2, DW_OP_plus, DW_OP_LLVM_arg, 1, DW_OP_plus, DW_OP_stack_value)), !dbg !135225

We're seeing a pathological case with 36ec97f76ac0d8be76fb16ac521f55126766267d (3rd Reapply "[DebugInfo] Use variadic debug values to salvage BinOps and GEP instrs with non-const operands).

I didn't encounter any such cases while testing this patch, but it's certainly possible for it to occur. Personally, I think the best approach for this is to impose a limit on the number of args that can be added to a DIArgList by salvaging - it's clear that it is not feasible to salvage everywhere we possibly can. I think that a max of 32 is probably a reasonable amount, but if you have a reproducer for this issue I can do some performance testing myself to more accurately determine a sensible limit.

I do believe that InstCombine also has a problem with massively inflating the number of debug intrinsics in a function; the slowdown factor you're seeing is probably the product of these two factors.

We're seeing a pathological case with 36ec97f76ac0d8be76fb16ac521f55126766267d (3rd Reapply "[DebugInfo] Use variadic debug values to salvage BinOps and GEP instrs with non-const operands).

I didn't encounter any such cases while testing this patch, but it's certainly possible for it to occur. Personally, I think the best approach for this is to impose a limit on the number of args that can be added to a DIArgList by salvaging - it's clear that it is not feasible to salvage everywhere we possibly can. I think that a max of 32 is probably a reasonable amount, but if you have a reproducer for this issue I can do some performance testing myself to more accurately determine a sensible limit.

I do believe that InstCombine also has a problem with massively inflating the number of debug intrinsics in a function; the slowdown factor you're seeing is probably the product of these two factors.

The case we hit is from an internal codebase. Thanks for the fix in D103162. I will try 16 and 32 as the limit and report back there.

Thanks for the report -- we're out of working hours in the UK timezone and I can't revert myself, if you could revert this for us, please do.

We are investigating now. I looks like this assert only fires in combination with WebAssemlby change that was landed between the 2nd and 3rd re-landing: https://reviews.llvm.org/D102589. I think we will try to fix forward if we can and if that fails revert either or the other.

This turned out to be a bug in WebAssembly side. We fixed it so nevermind!

Thanks for the report -- we're out of working hours in the UK timezone and I can't revert myself, if you could revert this for us, please do.

We are investigating now. I looks like this assert only fires in combination with WebAssemlby change that was landed between the 2nd and 3rd re-landing: https://reviews.llvm.org/D102589. I think we will try to fix forward if we can and if that fails revert either or the other.

This turned out to be a bug in WebAssembly side. We fixed it so nevermind!

Might be handy to include a link to the fix here for context (in case other folks with out of tree backends hit similar issues, etc)

Might be handy to include a link to the fix here for context (in case other folks with out of tree backends hit similar issues, etc)

I believe the fix in question is here: D102999

hans added a subscriber: hans.Jun 7 2021, 6:49 AM

We're seeing build non-determinism in Chromium after this patch (after 36ec97f76ac0d8be76fb16ac521f55126766267d specifically). See https://bugs.chromium.org/p/chromium/issues/detail?id=1216316#c20 for a reproducer.

aeubanks added inline comments.
llvm/lib/Transforms/Utils/Local.cpp
1791

could this be causing non-determinism?

hans added a comment.Jun 8 2021, 5:58 AM

Reverted in 386b66b2fc297cda121a3cc8a36887a6ecbcfc68 until this can be fixed.

llvm/lib/Transforms/Utils/Local.cpp
1791

I tried changing VariableOffsets into a MapVector, but that wasn't enough to make the output of my reproducer deterministic.

StephenTozer added inline comments.Jun 10 2021, 7:49 AM
llvm/lib/Transforms/Utils/Local.cpp
1791

This is a potential source of non-determinism, but in this case it was actually in a different piece of code from an earlier patch, although this patch depends on that one and exposes the incorrect behaviour. I'm opening up a patch to fix that other incorrect behaviour, and will also fix this in the next reapply.

This revision was not accepted when it landed; it landed in state Needs Revision.Jun 24 2021, 1:49 AM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
thakis added a subscriber: thakis.Jun 28 2021, 8:28 AM

https://reviews.llvm.org/rGadace79652174d126be290cab42b3122569fe15d made llvm crash (or assert, when assertions are on) when building some chromium binary: https://bugs.chromium.org/p/chromium/issues/detail?id=1224338

Given how many reverts this went through and given that this commit was structured to be optimized for reverts, I went ahead and revert that in 540b4a5fb31086b6d40735e96e6ec497022107e7

https://reviews.llvm.org/rGadace79652174d126be290cab42b3122569fe15d made llvm crash (or assert, when assertions are on) when building some chromium binary: https://bugs.chromium.org/p/chromium/issues/detail?id=1224338

Given how many reverts this went through and given that this commit was structured to be optimized for reverts, I went ahead and revert that in 540b4a5fb31086b6d40735e96e6ec497022107e7

Here's a stand-alone repro for that crash: https://bugs.chromium.org/p/chromium/issues/detail?id=1224338#c5 , https://bugs.chromium.org/p/chromium/issues/detail?id=1224338#c6

The relanding in 47633af9d4a8b93f50cb711cf23489736e0226f1 broke determinism for Firefox.

StephenTozer added a comment.EditedNov 8 2021, 1:38 AM

The relanding in 47633af9d4a8b93f50cb711cf23489736e0226f1 broke determinism for Firefox.

Do you have any more info about the non-deterministic build? If there's a reduced or packaged reproducer that would be ideal, and a link to a buildbot demonstrating the failure would also be very helpful. Otherwise, knowing which version of Firefox the non-determinism shows up in and the build flags+config would be useful, along with any more details about where the non-determinism appears specifically (i.e. which object file(s)).

The relanding in 47633af9d4a8b93f50cb711cf23489736e0226f1 broke determinism for Firefox.

Has the non-determinism problem been fixed with the landing of rG3c47c5ca13b8a502de3272e8105548715947b7a8?

glandium added a comment.EditedNov 10 2021, 1:29 PM

The relanding in 47633af9d4a8b93f50cb711cf23489736e0226f1 broke determinism for Firefox.

Has the non-determinism problem been fixed with the landing of rG3c47c5ca13b8a502de3272e8105548715947b7a8?

That seems to fix the non-determinism issue introduced in D106585, but not this one. It seems this was fixed on trunk, though. I'm bisecting to find what fixed it.

Edit: rGbadcd585897253e94b7b2d4e6f9f430a2020d642 is what fixed this one.