[PATCH] unique_ptrify llvm::getLazyBitcodeModule's MemoryBuffer parameter
Rafael EspĂndola
rafael.espindola at gmail.com
Wed Aug 13 09:03:18 PDT 2014
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)?
On 12 August 2014 17:51, David Blaikie <dblaikie at gmail.com> wrote:
> Hi lhames, rafael,
>
> 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.
>
> http://reviews.llvm.org/D4876
>
> Files:
> include/llvm/ADT/ScopeGuard.h
> include/llvm/Bitcode/ReaderWriter.h
> include/llvm/IR/GVMaterializer.h
> include/llvm/IR/Module.h
> lib/Bitcode/Reader/BitReader.cpp
> lib/Bitcode/Reader/BitcodeReader.cpp
> lib/Bitcode/Reader/BitcodeReader.h
> lib/IR/Module.cpp
> lib/IRReader/IRReader.cpp
> lib/LTO/LTOModule.cpp
> lib/Object/IRObjectFile.cpp
> unittests/Bitcode/BitReaderTest.cpp
> unittests/ExecutionEngine/JIT/JITTest.cpp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 4030 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140813/1657d06e/attachment.bin>
More information about the llvm-commits
mailing list