[llvm-commits] [PATCH] Dwarf: support for LTO where a single object file can have multiple line tables

[Manman Ren]

On Jan 30, 2013, at 5:28 PM, Eric Christopher <echristo at gmail.com> wrote:

> 
>> Any thoughts here? 
> I used MCLineIDs for fast look-up, do you have any suggestion on what to use here?
> 
> 
> It took me a while, but I see what you're doing. Effectively I think you can just use a lookup in MCLineDivisionsto see if anything is in the set? Since the SmallSet is going to be stored in exactly the same way anyhow. Also since I've not bothered to look are the CU ids dense or sparse? i.e. 0, 1, 2 or in metadata node order (0, 12, 255, 444)?

The CU ids will be 0,1,2, …
I tried to use count on MCLineDivisions, but it takes a long time.
MCLineDivisions keeps a vector of Line Entries for each CUID, and the size of vector can be large.
find(int CUID) is pretty fast if the map contains an entry for CUID, but will be slow when it does not.
I will try std::map.

>  
>>> The bit with CUID = -1 or CUID == 0 seems confusing, can you explain this a bit? At times -1 seems to be for invalid CUs and at other times the first/only CU?
>> "-1" is the default CUID, when DwarfDebug does not exist.
>> So the first line table will be for CUID 0 when DwarfDebug exists, and will be for CUID -1 when DwarfDebug does not exist.
>> 
>> 
>> This seems a bit confusing. Since, for example, we emit a CU for assembly files and so something will always be emitting a CU. I could easily not be seeing something though. At worst it really needs some comments.
> I added some comments.
> +  // CUID and MCLineTableSymbols are set in DwarfDebug, when DwarfDebug does
> +  // not exist, CUID will be -1 and MCLineTableSymbols will be empty. 
> 
> Updated patch is attached.
> 
> 
> Right. I'm not sure why this division exists. Is there some reason why it's -1 in the other case that I'm missing?
We can probably use 0 as the default value, but is there something wrong with -1 meaning no DwarfDebug?

Thanks,
Manman
> 
> -eric 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130130/9b9f9808/attachment.html>