[LLVMdev] Troubleshooting Internal Garbage Collection

[Craig Topper]

removeFromParent just unlinks it from the basic block and returns the
removed instruction. It does not delete it.

On Sun, Jan 20, 2013 at 9:54 PM, David Waggoner <mathonnapkins at gmail.com>wrote:

>
> Thanks for the suggestion, Duncan.
>
> I recently figured out that it had to do with how I was removing the
> pseudo instruction in my overridden expandPostRAPseudo() implementation.
>
> // member function's signature
> bool TheInstrInfo::expandPostRAPseudo(MachineBasicBlock::iterator p_mi)
>
> // works
> bb.erase(p_mi);
>
> // produces the assertion / memory leak.
> p_mi->removeFromParent();
>
> I should have looked more closely at the targets that implemented
> expandPostRAPseudo() and saw how they got rid of the pseudo instruction. In
> particular, the successful line was lifted from bool
> Mips16InstrInfo::expandPostRAPseudo(...). Some targets don't eliminate the
> pseudo, but rather reconfigure it to be native.
>
> In any case, I don't quite understand why these two seemingly (to me)
> equivalent lines of code cause different behavior at run time. For
> reference, each of my pseudo instructions expands to 2 or more native
> instructions. p_mi->removeFromParent() seems to be used in other targets (
> but not expandPostRAPseudo() ) without issue.... *shrug*.
>
> Sincerely,
> ~ MathOnNapkins / David
>
>
> On Mon, Jan 14, 2013 at 4:14 AM, Duncan Sands <baldrick at free.fr> wrote:
>
>> Hi David,
>>
>>
>> > Previously, I had been testing with only one routine per test .ll file,
>> but I
>>
>>> thought I'd reached a point where I could test multiple operations at
>>> once and
>>> understand the output. The odd part about this is that the likelihood of
>>> seeing
>>> the above assertion scales with the number of functions in the .ll file.
>>> If I
>>> have one or two functions, I never see it. With three, I see it
>>> sporadically.
>>> With four or five, I see it about 80% of the time. I don't understand
>>> why it
>>> would only assert some of the time, as the inputs are not changing.
>>>
>>
>> memory corruption or uninitialized variable maybe?  Try running under
>> valgrind.
>>
>> Ciao, Duncan.
>>
>>  Could it be
>>
>>> a problem with my system itself, or perhaps I'm running low on RAM? If
>>> anybody
>>> has any insight on how to troubleshoot this kind of problem, i'd be very
>>> grateful.
>>>
>>> Also, I have not overriden runOnMachineFunction() in my
>>> XXXISelDagToDag.cpp
>>> file, so this is happening somewhat out of my control. Should I attempt
>>> to
>>> override it? I noticed that only a couple targets actually override
>>> runOnMachineFunction() for that particular pass (MIPS, I think is one).
>>>
>>> Sincerely,
>>> ~MathOnNapkins / Dave
>>>
>>>
>>>
>>> ______________________________**_________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>>
>>>
>> ______________________________**_________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>


-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130120/3d321185/attachment.html>