<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 11:10 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On 2015-Jan-13, at 11:02, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Jan 13, 2015 at 10:57 AM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
><br>
> > On 2015-Jan-13, at 10:55, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Tue, Jan 13, 2015 at 10:45 AM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> ><br>
> > > On 2015-Jan-13, at 10:23, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > > On Mon, Jan 12, 2015 at 5:04 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> > ><br>
> > > > On 2015-Jan-12, at 15:02, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > On Mon, Jan 12, 2015 at 2:46 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
> > > > Author: dexonsmith<br>
> > > > Date: Mon Jan 12 16:46:15 2015<br>
> > > > New Revision: 225721<br>
> > > ><br>
> > > > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=225721&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=225721&view=rev</a><br>
> > > > Log:<br>
> > > > IR: Fix unit test memory leak reported by ASan<br>
> > > ><br>
> > > > <a href="http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/603/steps/check-llvm%20asan/logs/stdio" target="_blank">http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/603/steps/check-llvm%20asan/logs/stdio</a><br>
> > > ><br>
> > > > Thanks Alexey for pointing me to this!<br>
> > > ><br>
> > > > Modified:<br>
> > > > llvm/trunk/unittests/IR/MetadataTest.cpp<br>
> > > ><br>
> > > > Modified: llvm/trunk/unittests/IR/MetadataTest.cpp<br>
> > > > URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/IR/MetadataTest.cpp?rev=225721&r1=225720&r2=225721&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/IR/MetadataTest.cpp?rev=225721&r1=225720&r2=225721&view=diff</a><br>
> > > > ==============================================================================<br>
> > > > --- llvm/trunk/unittests/IR/MetadataTest.cpp (original)<br>
> > > > +++ llvm/trunk/unittests/IR/MetadataTest.cpp Mon Jan 12 16:46:15 2015<br>
> > > > @@ -314,6 +314,7 @@ TEST_F(MDNodeTest, handleChangedOperandR<br>
> > > > Metadata *Ops3[] = {N2};<br>
> > > > MDNode *N3 = MDNode::get(Context, Ops3);<br>
> > > > Temp3->replaceAllUsesWith(N3);<br>
> > > > + delete Temp3;<br>
> > > ><br>
> > > > unique_ptr?<br>
> > ><br>
> > > Good idea. r225749 (and I used it in the next test I added).<br>
> > ><br>
> > > ><br>
> > > > (perhaps, eventually, we could change MDNode::getTemporary to return unique_ptr - or we could change it now, make the existing callers release() and fix them whenever we feel like it)<br>
> > ><br>
> > > I'm not sure that'll be worth it (although I'm not particularly<br>
> > > opposed). Reason being that (outside of unit tests) these are<br>
> > > typically dropped into MDNodes and not stored anywhere, then fixed<br>
> > > up later.<br>
> > ><br>
> > > What do you mean by fixed up later? Given that the temporary nodes have to be manually managed by the caller (previously you had to call deleteTemporary, now you can just use delete directly) I would imagine all users would have a side table of pointers to these nodes so they could clean them up. At least I think that's true for debug info's temporary nodes... -<br>
> ><br>
> > So right now DIBuilder keeps track of nodes that *point* at<br>
> > temporary nodes, not the temporary nodes themselves. The temporary<br>
> > nodes are found again as operands of the tracked nodes.<br>
> ><br>
> > > OK, so DIDescriptor likes to be a bit 'relaxed' and store both owning and non-owning pointers in the DbgNode (& callers just have to know that they must RAUW it, and leak if they don't) - but that seems a sub-optimal API that might be improved by forcing unique_ptr through things... maybe.<br>
> ><br>
> > This isn't just a `DIDescriptor` thing -- the only place the nodes<br>
> > are actually stored right now are in `MDOperand`, which definitely<br>
> > does not own its operands right now (although I have thought about<br>
> > adding reference counting there).<br>
> ><br>
> > Not sure I follow here - DIDescriptor::replaceAllUsesWith replaces itself (the DbgNode member, with a permanent copy). It doesn't look like it's dealing with a node in an MDOperand.<br>
> ><br>
> > Looking at CGDebugInfo::finalize I believe every DIDescriptor in ObjCInterfaceCache, ReplaceMap, and FwDeclReplaceMap are DIDescriptor's whos DbgNode is a temporary node and needs to be replaced and explicitly deleted. So this is making DIDescriptor's DbgNode a 'maybe owning' smart pointer (except the maybe-owning-ness is being tracked externally, so it doesn't use an extra bit to store that knowledge internally).<br>
><br>
> I was looking at `DIBuilder::finalize()`, which follows the pattern<br>
> I just described.<br>
><br>
> Not sure I follow there either.<br>
><br>
> The TempBlah MDNode*s are the actual MDNodes being replaced, not pointers to nodes that point at the temporaries - indeed all of those are owning pointers (they are only ever assigned the result of MDNode::getTemporary) & could be std::unique_ptrs. Then in finalize we build a DIDescriptor (losing type safety of ownership here) which nown 'owns' the pointer and we call DIDescriptor::replaceAllUsesWith which then replaces it and deletes the temporary node.<br>
<br>
</div></div>(adding back llvm-commits)<br>
<br>
I read the code carelessly, and assumed it was all done like<br>
subprograms:<br>
<br>
for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++i) {<br>
DISubprogram SP(SPs.getElement(i));<br>
if (MDNode *Temp = SP.getVariablesNodes()) {<br>
SmallVector<Metadata *, 4> Variables;<br>
for (Metadata *V : PreservedVariables.lookup(SP))<br>
Variables.push_back(V);<br>
DIArray AV = getOrCreateArray(Variables);<br>
DIType(Temp).replaceAllUsesWith(AV);<br>
}<br>
}<br>
<br>
You're right -- *almost* all cases are done like you said.<br></blockquote><div><br>Heh, fair enough - I only looked at one or two places & assumed it was all the same. Just got lucky I guess.<br><br>Anyway.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
> But maybe I'm confused/we're talking past each other?<br>
><br>
> - David<br>
><br>
><br>
> Looked like the same pattern is done two different ways :/.<br>
><br>
> ><br>
> > However, as I said before, I'm not really opposed. Outside of<br>
> > debug info -- the only schema with long-lived forward declarations<br>
> > -- I think returning `std::unique_ptr<>` makes a ton of sense.<br>
> > (Although their only apparent use outside of debug info it to set<br>
> > up self-references to defeat uniquing entirely, and we have a<br>
> > better solution for that now.)<br>
> ><br>
> > (Besides, we can probably design away the long-lived forward<br>
> > declarations. Aside from supporting cycles, their main use right<br>
> > now is to delay uniquing. It would be pretty easy to support this<br>
> > more directly (create a distinct node, update its operands, and<br>
> > then turning on uniquing -- the only part without API is that<br>
> > last step). Even without new API, if the tracked node itself was<br>
> > a forward declaration and *it* was the one that got RAUW'ed, we'd<br>
> > be set.)<br>
> ><br>
> > Certainly agreed with this last bit, I think... not quite sure how that'll all look, but yes - with better metadata functionality like explicit distinctness we might be able to do away with some of this.<br>
> ><br>
> > - David<br>
> ><br>
> ><br>
> > ><br>
> > > Given test coverage + ASan bots, I'm not sure<br>
> > > explicitly tracking them makes sense (I mean, that's the whole<br>
> > > reason the leak detector was deleted).<br>
> > ><br>
> > > ><br>
> > > ><br>
> > > > // !4 = !{!1}<br>
> > > > Metadata *Ops4[] = {N1};<br>
> > > ><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > llvm-commits mailing list<br>
> > > > <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> > > > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
> ><br>
> ><br>
<br>
</div></div></blockquote></div><br></div></div>