llvm dev - Jan 2013 - [LLVMdev] Troubleshooting Internal Garbage Collection

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>

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>

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>