[LLVMdev] Troubleshooting Internal Garbage Collection
David Waggoner
mathonnapkins at gmail.com
Sun Jan 20 21:54:18 PST 2013
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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130121/a77bfba4/attachment.html>
More information about the llvm-dev
mailing list