This is an archive of the discontinued LLVM Phabricator instance.

IR, Bitcode: Change bitcode reader to no longer own its memory buffer.
ClosedPublic

Authored by pcc on Nov 7 2016, 8:34 PM.

Details

Summary

Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as this patch shows, ownership can
often reside at a higher level. With the upcoming change to allow multiple
modules in a single bitcode file, it will no longer be appropriate for
modules to generally have unique ownership of their memory buffer.

The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext
and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for
the module to own the memory buffer. This patch does so by adding an owned
memory buffer field to Module, and using it in a few other places where it
is convenient.

Diff Detail

Repository
rL LLVM

Event Timeline

pcc updated this revision to Diff 77140.Nov 7 2016, 8:34 PM
pcc retitled this revision from to IR, Bitcode: Change bitcode reader to no longer own its memory buffer..
pcc updated this object.
pcc added reviewers: dexonsmith, mehdi_amini.
pcc added a subscriber: llvm-commits.
mehdi_amini added inline comments.Nov 7 2016, 8:51 PM
llvm/include/llvm/IR/Module.h
164 ↗(On Diff #77140)

What other legacy clients do we have? Is it only the C API? The C API can be handled differently: it can have its own wrapper struct around the Module class, and this wrapper would own the buffer.

mehdi_amini accepted this revision.Nov 7 2016, 9:56 PM
mehdi_amini edited edge metadata.

LGTM, with one nit inline.

llvm/include/llvm/IR/Module.h
811 ↗(On Diff #77140)

take seems reversed here, I usually see it the opposite way: when the client of the API takes ownership of something that is owned by the object.

This revision is now accepted and ready to land.Nov 7 2016, 9:56 PM
This revision was automatically updated to reflect the committed changes.