[llvm] r211595 - Pass a unique_ptr<MemoryBuffer> to the constructors in the Binary hierarchy.
Alp Toker
alp at nuanti.com
Fri Jul 4 18:42:06 PDT 2014
On 05/07/2014 04:03, Rafael EspĂndola wrote:
>> On the other hand it looks like you have exactly the same problem as the
>> clang frontend in this code because it needlessly unmaps and re-mmaps files
>> each time they're used, so why not work together on the solution?
> Sorry, where do we have that with ObjectFile?
Where? *All* current uses on ToT seem to mmap their own private
MemoryBuffer and un-mmap it immediately afterwards.
Peter's proposal to extract bitcode from object files makes that more
acute. If you have 16 LTO threads, or 16 sequential LTO runs linking 100
objects containing some of the same object files, that means 16000
mmaps, nearly of which are redundant.
This sounds like a similar problem space to header inclusion in the
clang frontend which why it makes sense to find a shared solution.
Of course, you may not be planning to run multiple LTOs in a single process:
What I'm asking is, why did these two commits add complexity and enforce
unique ownership of MemoryBuffer instances when nothing seems to require
unique ownership?
Your commit log says:
Once the objects are constructed, they own the buffer. Passing a
unique_ptr
makes that clear.
Unique ownership sounds like the exact opposite of what we want so I'd
expect the commit log to contain some rationale. Why do these parameters
need to pass around a unique memory buffer instance?
Alp.
>
> Cheers,
> Rafael
--
http://www.nuanti.com
the browser experts
More information about the llvm-commits
mailing list