[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