search for: valuemateri

...t/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::Va...

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

...ot/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::Remap...

...bLLVM-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> > >&...

....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&...

...rather than basing it on the CloneFunction stuff. My current implementation is based on CloneAndPruneFunctionInto as you suggested, but I wondered if CodeExtractor might not be a better starting point. What do you think? Also, at the moment I’m more or less ignoring the frame variable issue. My ValueMaterializer is just creating new allocas with the name I want. I think that will be easy enough to patch up once your llvm.frameallocate stuff is in place. The implication of this is that right now I’m not looking for live variables before I start outlining, I’m just picking them up as I go. It seems...

> We should also think about how to call std::terminate when cleanup dtors throw. The current representation for Itanium is inefficient. As a strawman, I propose making @__clang_call_terminate an intrinsic: … That sounds like a good starting point. > Chandler expressed strong concerns about this design, however, as @llvm.eh.get_capture_block adds an ordering constraint on CodeGen. Once