The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with bitcode and assembly changes!
On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote:> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the > C++ side of it. This was a rocky day, but I suppose that's what I get > for failing to stage the change in smaller pieces. > > As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, > so if I've missed some problem in the sea of buildbot errors, please > flag me down. > > I'll follow up soon with bitcode and assembly changes!Hi Duncan, I started getting random assertion failures in some tests yesterday, and I think it may be related to this change. Here is the stack trace: #0 0x00007ffff59f4c39 in raise () from /lib64/libc.so.6 #1 0x00007ffff59f6348 in abort () from /lib64/libc.so.6 #2 0x00007ffff59edb96 in __assert_fail_base () from /lib64/libc.so.6 #3 0x00007ffff59edc42 in __assert_fail () from /lib64/libc.so.6 #4 0x00007ffff3a30e92 in llvm::LeakDetectorImpl<void>::addGarbage(void const*) [clone .part.19] () from /opt/buildbot/lib/libLLVM-3.6svn.so #5 0x00007ffff3a30fd3 in llvm::LeakDetector::addGarbageObjectImpl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>) () from /opt/buildbot/lib/libLLVM-3.6svn.so #7 0x00007ffff3426b3f in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #8 0x00007ffff3426bd6 in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #9 0x00007ffff3426bd6 in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #10 0x00007ffff3426eed in llvm::MapValue(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #11 0x00007ffff3426f39 in llvm::MapValue(llvm::MDNode const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #12 0x00007ffff3427174 in llvm::RemapInstruction(llvm::Instruction*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #13 0x00007ffff3755786 in (anonymous namespace)::ModuleLinker::linkGlobalValueBody(llvm::GlobalValue&) () from /opt/buildbot/lib/libLLVM-3.6svn.so #14 0x00007ffff375767f in llvm::Linker::linkInModule(llvm::Module*) () from /opt/buildbot/lib/libLLVM-3.6svn.so #15 0x00007ffff3758cfb in llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::function<void (llvm::DiagnosticInfo const&)>) () from /opt/buildbot/lib/libLLVM-3.6svn.so #16 0x00007ffff6c9d8cf in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) () from /opt/buildbot/lib/libOpenCL.so.1 #17 0x00007ffff6e61f23 in clang::ParseAST(clang::Sema&, bool, bool) () from /opt/buildbot/lib/libOpenCL.so.1 #18 0x00007ffff6c9e6bb in clang::CodeGenAction::ExecuteAction() () from /opt/buildbot/lib/libOpenCL.so.1 #19 0x00007ffff6b7ead6 in clang::FrontendAction::Execute() () from /opt/buildbot/lib/libOpenCL.so.1 #20 0x00007ffff6b5d179 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () from /opt/buildbot/lib/libOpenCL.so.1 #21 0x00007ffff6b1282c in (anonymous namespace)::compile_llvm (llvm_ctx=..., source="\n__kernel void test_fn(__local float *sSharedStorage, __global float *srcValues, __global uint *offsets, __global float *destBuffer, uint alignmentOffset )\n{\n int tid = get_global_id( 0 );\n sSha"..., headers=..., name="input.cl", triple="r600--", processor="verde", opts="", address_spaces=..., optimization_level=@0x7fffffff21cc: 2, r_log=...) at llvm/invocation.cpp:255 #22 0x00007ffff6b140c8 in clover::compile_program_llvm (source=..., headers=..., ir=ir at entry=PIPE_SHADER_IR_NATIVE, target=..., opts=..., r_log=...) at llvm/invocation.cpp:710 #23 0x00007ffff6b0a371 in clover::program::build (this=this at entry=0x23a0530, devs=..., opts=opts at entry=0x7ffff793dc0d "", headers=...) at core/program.cpp:63 #24 0x00007ffff6af31c4 in clBuildProgram (d_prog=0x23a0538, num_devs=0, d_devs=0x0, p_opts=<optimized out>, pfn_notify=0x0, user_data=0x0) at api/program.cpp:182 Does this look related? If so, let me know what other information you need to try to debug this issue. Thanks, Tom> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >> >> As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, >> so if I've missed some problem in the sea of buildbot errors, please >> flag me down. >> >> I'll follow up soon with bitcode and assembly changes! > > Hi Duncan, > > I started getting random assertion failures in some tests yesterday, and I think > it may be related to this change. Here is the stack trace: > > #0 0x00007ffff59f4c39 in raise () from /lib64/libc.so.6 > #1 0x00007ffff59f6348 in abort () from /lib64/libc.so.6 > #2 0x00007ffff59edb96 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x00007ffff59edc42 in __assert_fail () from /lib64/libc.so.6 > #4 0x00007ffff3a30e92 in llvm::LeakDetectorImpl<void>::addGarbage(void const*) [clone .part.19] () from /opt/buildbot/lib/libLLVM-3.6svn.so > #5 0x00007ffff3a30fd3 in llvm::LeakDetector::addGarbageObjectImpl(void*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #6 0x00007ffff3a40eed in llvm::MDNode::getTemporary(llvm::LLVMContext&, llvm::ArrayRef<llvm::Metadata*>) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #7 0x00007ffff3426b3f in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #8 0x00007ffff3426bd6 in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #9 0x00007ffff3426bd6 in MapValueImpl(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #10 0x00007ffff3426eed in llvm::MapValue(llvm::Metadata const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #11 0x00007ffff3426f39 in llvm::MapValue(llvm::MDNode const*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #12 0x00007ffff3427174 in llvm::RemapInstruction(llvm::Instruction*, llvm::ValueMap<llvm::Value const*, llvm::WeakVH, llvm::ValueMapConfig<llvm::Value const*, llvm::sys::SmartMutex<false> > >&, llvm::RemapFlags, llvm::ValueMapTypeRemapper*, llvm::ValueMaterializer*) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #13 0x00007ffff3755786 in (anonymous namespace)::ModuleLinker::linkGlobalValueBody(llvm::GlobalValue&) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #14 0x00007ffff375767f in llvm::Linker::linkInModule(llvm::Module*) () from /opt/buildbot/lib/libLLVM-3.6svn.so > #15 0x00007ffff3758cfb in llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::function<void (llvm::DiagnosticInfo const&)>) () > from /opt/buildbot/lib/libLLVM-3.6svn.so > #16 0x00007ffff6c9d8cf in clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) () from /opt/buildbot/lib/libOpenCL.so.1 > #17 0x00007ffff6e61f23 in clang::ParseAST(clang::Sema&, bool, bool) () from /opt/buildbot/lib/libOpenCL.so.1 > #18 0x00007ffff6c9e6bb in clang::CodeGenAction::ExecuteAction() () from /opt/buildbot/lib/libOpenCL.so.1 > #19 0x00007ffff6b7ead6 in clang::FrontendAction::Execute() () from /opt/buildbot/lib/libOpenCL.so.1 > #20 0x00007ffff6b5d179 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) () from /opt/buildbot/lib/libOpenCL.so.1 > #21 0x00007ffff6b1282c in (anonymous namespace)::compile_llvm (llvm_ctx=..., > source="\n__kernel void test_fn(__local float *sSharedStorage, __global float *srcValues, __global uint *offsets, __global float *destBuffer, uint alignmentOffset )\n{\n int tid = get_global_id( 0 );\n sSha"..., headers=..., name="input.cl", triple="r600--", processor="verde", opts="", > address_spaces=..., optimization_level=@0x7fffffff21cc: 2, r_log=...) at llvm/invocation.cpp:255 > #22 0x00007ffff6b140c8 in clover::compile_program_llvm (source=..., headers=..., ir=ir at entry=PIPE_SHADER_IR_NATIVE, target=..., opts=..., r_log=...) > at llvm/invocation.cpp:710 > #23 0x00007ffff6b0a371 in clover::program::build (this=this at entry=0x23a0530, devs=..., opts=opts at entry=0x7ffff793dc0d "", headers=...) > at core/program.cpp:63 > #24 0x00007ffff6af31c4 in clBuildProgram (d_prog=0x23a0538, num_devs=0, d_devs=0x0, p_opts=<optimized out>, pfn_notify=0x0, user_data=0x0) > at api/program.cpp:182 > > Does this look related? If so, let me know what other information you need to > try to debug this issue.This could be related; I'm not sure. It looks like a leak detection assertion, and I didn't need to change that logic at all. `ValueMap` calls `MDNode::getTemporary()` and `MDNode::deleteTemporary()` in the same ways it used to (and I didn't touch the implementation of those). Can you reproduce this with `llvm-link`? If so, that sounds like the best place to start.
Hi Duncan, I'm in the following situation for which this change caused an assertion failure: Three modules, let's say A B C Two function, F in A, G in B Now I CloneFunction F into B (call the new function F') and inline F' into G. Now, for the problematic part, where I try to extract G (and all referenced values) into C: upon encountering any debug node in the inlined code, it tries to clone the DISubprogram for F', so it creates a temporary. Since that refers to F', it'll now go ahead and copy F'. However, here once again it tries to copy the DISubprogram, which now just uses the temporary value from above (this is fine). Unfortunately, right after, it calls resolveCycles on the debug info annotation, which crashes with Assertion failed: (!isa<MDNodeFwdDecl>(Op) && "Expected all forward declarations to be resolved"), function resolveCycles, file /Users/kfischer/julia/deps/llvm-svn/lib/IR/Metadata.cpp, line 459. because we still have the temporary DISubprogram in there. Any ideas what to do about this? On Wed, Dec 10, 2014 at 12:22 AM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote:> > The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the > C++ side of it. This was a rocky day, but I suppose that's what I get > for failing to stage the change in smaller pieces. > > As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, > so if I've missed some problem in the sea of buildbot errors, please > flag me down. > > I'll follow up soon with bitcode and assembly changes! > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141218/ceba8024/attachment.html>
> On 2014-Dec-18, at 01:43, Keno Fischer <kfischer at college.harvard.edu> wrote: > > Hi Duncan, > > I'm in the following situation for which this change caused an assertion failure: > > Three modules, let's say A B C > Two function, F in A, G in B > > Now I CloneFunction F into B (call the new function F') and inline F' into G. > Now, for the problematic part, where I try to extract G (and all referenced values) into C: > > upon encountering any debug node in the inlined code, it tries to clone the DISubprogram for F', so it creates a temporary. Since that refers to F', it'll now go ahead and copy F'. However, here once again it tries to copy the DISubprogram, which now just uses the temporary value from above (this is fine). Unfortunately, right after, it calls resolveCycles on the debug info annotation, which crashes with > > Assertion failed: (!isa<MDNodeFwdDecl>(Op) && "Expected all forward declarations to be resolved"), function resolveCycles, file /Users/kfischer/julia/deps/llvm-svn/lib/IR/Metadata.cpp, line 459. > > because we still have the temporary DISubprogram in there. > > Any ideas what to do about this? >The logic I have between `MapValue(Metadata*)` and `MapValueImpl(Metadata*)` was supposed to solve this. (Actually, those names are awful, I may try to change them to `MapMetadata()`.) The logical flow should be: - MapValue(Metadata*) calls MapValueImpl(). - MapValueImpl() introduces a temporary. - MapValueImpl() recursively calls MapValueImpl(). - MapValueImpl() resolves its temporary. - MapValue(Metadata*) calls resolveCycles(). There could be a bug here, but I just scanned the code and it seems to match up. I suspect, rather, that there's a temporary node in the metadata graph on entry to `CloneFunction()`; this isn't supported, and would cause the same assertion to fire. Try running the verifier right before calling `CloneFunction()`: I put a check for this in `Verifier::visitMDNode()`.