[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