[llvm-commits] [llvm] r148653 - in /llvm/trunk: include/llvm/Object/ObjectFile.h include/llvm/Support/Endian.h lib/Object/ELFObjectFile.cpp

[Jim Grosbach]

On Jan 23, 2012, at 11:35 PM, Bendersky, Eli wrote:

>> -----Original Message-----
>> From: Jim Grosbach [mailto:grosbach at apple.com]
>> Sent: Monday, January 23, 2012 20:38
>> To: Bendersky, Eli
>> Cc: llvm-commits at cs.uiuc.edu
>> Subject: Re: [llvm-commits] [llvm] r148653 - in /llvm/trunk:
>> include/llvm/Object/ObjectFile.h include/llvm/Support/Endian.h
>> lib/Object/ELFObjectFile.cpp
>> 
>> Hi Eli,
>> 
>> This patch uses std::vector quite a lot. Have you considered SmallVector? It
>> seems likely that may be a better fit in at least some cases.
>> 
>> -Jim
>> 
> 
> Hi Jim,
> 
> Thanks for taking the time to review the patch. We'll be happy for the code to conform to the LLVM coding philosophy, but would be happy for some advice. We did consider SmallVector, but eventually just went with std::vector. Here is the reasoning.
> 
> Currently std::vector is used in 2 places in the added code:
> 
> 1. It's being passed to the constructor of DyldELFObject as a simple method of tracking memory allocations. The same vector is being passed by reference to other methods of the object. This solution is probably temporary, since we plan to eventually roll a more sophisticated memory manager (Ashok Thirumurthi explained this intention in a separate discussion earlier). This vector is created once in the calling code, and the functions in ELFObjectFile just add pointers to it with push_back.
> 2. Another std::vector is created in the rebaseObject method to keep track of the addresses of COMMON symbols. Note that we don't know in advance how many such symbols there are.
> 
> Also note that rebaseObject is just called once per JITted module.
> 
> IIUC, SmallVector's chief advantage over std::vector is that it can allocate some elements on the stack without malloc, so when we have a good guess of the maximal amount of elements the vector will contain, SmallVector provides a way to avoid a malloc.
> 
> In light of the above, which use(s) of std::vector would you recommend replacing with SmallVector?
> 
> Thanks in advance,
> Eli
> 
> 
> 

Hi Eli,

That's pretty similar to what the MachO side of things is doing. SmallVector<Ty, 0> is nearly equivalent to std::vector, so even just using it to optimize for a set of common cases w/ not too many objects in it can be very handy, especially when the contained objects are small like they are here.

I wouldn't go so far to say that it's a requirement to use SmallVector<> here or anything like that, but it would be my personal choice barring seeing actual performance comparisons demonstrating otherwise.

-Jim


> 
> 
> 
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>