[LLVMdev] Troubleshooting Internal Garbage Collection

[David Waggoner]

HI Craig,

That makes perfect sense then. *headdesk*. Assumptions are very bad.
Still... I wonder why it was asserting only some of the time, though.

Sincerely,
~ MathOnNapkins / David


On Mon, Jan 21, 2013 at 1:04 AM, Craig Topper <craig.topper at gmail.com>wrote:

> 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/20130121/475129ea/attachment.html>