This is an archive of the discontinued LLVM Phabricator instance.

unique_ptrify llvm::getLazyBitcodeModule's MemoryBuffer parameter
AbandonedPublic

Authored by dblaikie on Aug 12 2014, 2:51 PM.

Details

Reviewers
rafael
lhames
Summary

This turned out to be a bit tricky as there are some callers doing
strange things with ownership of the this MemoryBuffer.

A couple of callers (llvm::getBitcodeTargetTriple,
llvm::parseBitcodeFile) don't take ownership of the MemoryBuffer, but
still want to construct a Module (but they either ensure it's fully
materialized, or otherwise destroy it before the function is over, being
sure to take the MemoryBuffer back from the Module so it is not
destroyed). Some of these callers were adjusted to use ScopeGuards to
ensure the release of a fake local unique_ptr, others were able to be
adjusted to pass ownership transiently, then take it back again later.

Other ideas are welcome - one possible option would be to create new
shallow MemoryBuffers in these cases. Another would be to make these
data structures consistently non-owning, though that sounds difficult
for other users. I'd like to throw a few ideas around here because I
think this pattern shows up a few times in LLVM - where an API has
multiple users, some of whom want to give ownership, some of whom don't.
I'd like to figure out a good/consistent/simple answer for when we come
across this again.

Diff Detail

Event Timeline

dblaikie updated this revision to Diff 12420.Aug 12 2014, 2:51 PM
dblaikie retitled this revision from to unique_ptrify llvm::getLazyBitcodeModule's MemoryBuffer parameter.
dblaikie updated this object.
dblaikie added reviewers: lhames, rafael.
dblaikie added a subscriber: Unknown Object (MLST).
silvas added a subscriber: silvas.Aug 12 2014, 4:49 PM

Maybe this is worth another thread on LLVMDev, but I really dislike using unique_ptr when it complicates things. I see unique_ptr as a lightweight way ensure things are correct by default with no need to fiddle around; it should bring an immediate sense of security. Needing to have comments about ownership in code using unique_ptr defeats the purpose IMO.

I feel like this patch is really complicating things, trying to move towards unique_ptr just for the sake of using unique_ptr. There's no difference between a unique_ptr that needs to have careful comments about ownership around it vs. a raw pointer with careful comments about ownership, besides the possibility that the unique_ptr will possibly lure the reader into a false sense of security.

An unused-result call to .release() is as bad as raw new/delete: it is a manual, error-prone intervention for controlling an object's lifetime.

lib/Bitcode/Reader/BitcodeReader.cpp
3552–3554

What's the point of this? All std::move does is cast to T&&. You already have a T&&.

rafael edited edge metadata.Aug 13 2014, 9:03 AM

I am somewhat OK with this approach. I think the one item I feel
should be done differently is llvm::parseBitcodeFile. It can take just
a stringref and build a fake membuf to pass down. Maybe we should do
that first (attached patch)?

Looks like Rafael is already working on this in some more incremental
and probably better ways, so I'll defer to his work.

See Rafael's thread "[patch] Pass a MemoryBufferRef when we can avoid
taking ownership" for more details.

Here's a half-written email I had on this thread for a while. Just
sending for posterity.

dblaikie abandoned this revision.Aug 26 2014, 2:16 PM