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

[Andrew Trick]

On Feb 13, 2013, at 10:46 AM, Manman Ren <mren at apple.com> wrote:

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

Yep. Fairly obvious pasto. A fix will be in shortly.
-Andy

> ******************** 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/8bceb739/attachment.html>