[llvm] r175023 - Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.

[Manman Ren]

Hi Andy,

This is causing a bot failure, do you know what is wrong?

Thanks,
Manman
******************** TEST 'LLVM :: DebugInfo/X86/misched-dbg-value.ll' FAILED ********************
Script:
--
/build/buildbot/osu8/llvm-x86_64-linux-vg_leak/llvm/Debug+Asserts/bin/llc /build/buildbot/osu8/llvm-x86_64-linux-vg_leak/llvm/test/DebugInfo/X86/misched-dbg-value.ll -mtriple=x86_64-apple-darwin -filetype=obj -o /build/buildbot/osu8/llvm-x86_64-linux-vg_leak/llvm/test/DebugInfo/X86/Output/misched-dbg-value.ll.tmp -enable-misched
/build/buildbot/osu8/llvm-x86_64-linux-vg_leak/llvm/Debug+Asserts/bin/llvm-dwarfdump /build/buildbot/osu8/llvm-x86_64-linux-vg_leak/llvm/test/DebugInfo/X86/Output/misched-dbg-value.ll.tmp | /build/buildbot/osu8/llvm-x86_64-linux-vg_leak/llvm/Debug+Asserts/bin/FileCheck /build/buildbot/osu8/llvm-x86_64-linux-vg_leak/llvm/test/DebugInfo/X86/misched-dbg-value.ll
--
Exit Code: 123
Command Output (stderr):
--
==24760== 192 (176 direct, 16 indirect) bytes in 2 blocks are definitely lost in loss record 12 of 13
==24760==    at 0x4C29C97: operator new(unsigned long) (vg_replace_malloc.c:298)
==24760==    by 0x11BEE68: llvm::TargetInstrInfo::CreateTargetMIHazardRecognizer(llvm::InstrItineraryData const*, llvm::ScheduleDAG const*) const (TargetInstrInfo.cpp:558)
==24760==    by 0x10E1283: (anonymous namespace)::ConvergingScheduler::initialize(llvm::ScheduleDAGMI*) (MachineScheduler.cpp:1238)
==24760==    by 0x10DEB82: llvm::ScheduleDAGMI::schedule() (MachineScheduler.cpp:521)
==24760==    by 0x10DD9AC: (anonymous namespace)::MachineScheduler::runOnMachineFunction(llvm::MachineFunction&) (MachineScheduler.cpp:274)
==24760==    by 0x10AC5FC: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (MachineFunctionPass.cpp:33)
==24760==    by 0x151830C: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1530)
==24760==    by 0x15184FD: llvm::FPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1550)
==24760==    by 0x151885A: llvm::MPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1608)
==24760==    by 0x1518E5C: llvm::PassManagerImpl::run(llvm::Module&) (PassManager.cpp:1703)
==24760==    by 0x151906E: llvm::PassManager::run(llvm::Module&) (PassManager.cpp:1738)
==24760==    by 0x853B10: compileModule(char**, llvm::LLVMContext&) (llc.cpp:376)
==24760== 
==24760== 192 (176 direct, 16 indirect) bytes in 2 blocks are definitely lost in loss record 13 of 13
==24760==    at 0x4C29C97: operator new(unsigned long) (vg_replace_malloc.c:298)
==24760==    by 0x11BEE68: llvm::TargetInstrInfo::CreateTargetMIHazardRecognizer(llvm::InstrItineraryData const*, llvm::ScheduleDAG const*) const (TargetInstrInfo.cpp:558)
==24760==    by 0x10E12C3: (anonymous namespace)::ConvergingScheduler::initialize(llvm::ScheduleDAGMI*) (MachineScheduler.cpp:1239)
==24760==    by 0x10DEB82: llvm::ScheduleDAGMI::schedule() (MachineScheduler.cpp:521)
==24760==    by 0x10DD9AC: (anonymous namespace)::MachineScheduler::runOnMachineFunction(llvm::MachineFunction&) (MachineScheduler.cpp:274)
==24760==    by 0x10AC5FC: llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (MachineFunctionPass.cpp:33)
==24760==    by 0x151830C: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1530)
==24760==    by 0x15184FD: llvm::FPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1550)
==24760==    by 0x151885A: llvm::MPPassManager::runOnModule(llvm::Module&) (PassManager.cpp:1608)
==24760==    by 0x1518E5C: llvm::PassManagerImpl::run(llvm::Module&) (PassManager.cpp:1703)
==24760==    by 0x151906E: llvm::PassManager::run(llvm::Module&) (PassManager.cpp:1738)
==24760==    by 0x853B10: compileModule(char**, llvm::LLVMContext&) (llc.cpp:376)


On Feb 13, 2013, at 9:23 AM, Eric Christopher <echristo at gmail.com> wrote:

> 
> 
> On Wed, Feb 13, 2013 at 9:20 AM, Andrew Trick <atrick at apple.com> wrote:
> 
> On Feb 12, 2013, at 10:00 PM, Eric Christopher <echristo at gmail.com> wrote:
>>> 
>> 
>>>  Any reason why these aren't going into the pass impl?
>> They can be put in the pass impl. Is there an advantage of one vs. the other?
>> 
>> 
>> *shrug* Everything else in the implementation of the pass is in there... I'm at a loss on occasion why some things have pImpls. :)
>>  
> 
> Private non-inline stuff should be in the pImpl. Sorry I missed that when I reviewed the diff.
> 
> The MI sched specific test case is needed to hit this assertion. It invalidates LDV, which would then rerun on machine code sans-DGB_VALUEs. Not good.
> 
> Aha, that makes everything make a lot more sense.
> 
> Thanks Andy.
> 
> -eric 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130213/1d30555a/attachment.html>