<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 21, 2013 at 2:27 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Mon, Oct 14, 2013 at 4:14 PM, Manman Ren <<a href="mailto:manman.ren@gmail.com">manman.ren@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Oct 14, 2013 at 1:08 PM, Manman Ren <<a href="mailto:manman.ren@gmail.com">manman.ren@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Oct 11, 2013 at 12:40 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> >> It depends upon the goals. If the goal is to make debug information<br>
>>> >> post-link smaller then just using the type hashing machinery for<br>
>>> >> structs will be sufficient.<br>
>>> ><br>
>>> ><br>
>>> > By "the type hashing machinery for structs", are you referring to the<br>
>>> > type<br>
>>> > hashing at the back end?<br>
>>> ><br>
>>><br>
>>> I am, yes, since there's no other place we do currently.<br>
>>><br>
>>> >><br>
>>> >> However, if it's to save space during an<br>
>>> >> LTO link then we'll want to do it in the front end.<br>
>>> ><br>
>>> ><br>
>>> > Yes, my purpose here is to save memory space in number of MDNodes (also<br>
>>> > # of<br>
>>> > DIEs) generated in a LTO build.<br>
>>> > Type hashing at the DIE level can reduce the dwarf size.<br>
>>> ><br>
>>><br>
>>> I agree with both of these statements.<br>
>>><br>
>>> I also agree with the desire to help LTO memory consumption so we'll<br>
>>> need something from the front end for this since we'd like to continue<br>
>>> to use the folding set to do the uniquing.<br>
>><br>
>><br>
>> Hi Eric,<br>
>><br>
>> Assume that we need to do type hashing (i.e. assume Doug's rules for<br>
>> merging C types do not apply),<br>
><br>
><br>
> Now the assumption is true, any opinion on where to do the hashing?<br>
><br>
<br>
</div></div>We should still do it in the front end for the types with a language<br>
specific way. Nothing has greatly changed versus, say, C++ here - it's<br>
just easier in C++ because of the language.<br></blockquote><div><br></div><div>Hi Eric,</div><div><br></div><div>We don't have any hashing implementation in the front end, so I don't quite get what you mean</div>
<div>by "still do it in the front end" :)</div><div><br></div><div>For C++, we don't need to hash the types because of ODR. For other languages, is it better</div><div>to hash the MDNodes instead of the AST nodes because of the following?</div>
<div>1: we can handle all languages without ODR</div><div>2: we don't need to update each front-end that tries to take advantage of type uniquing</div><div>3: the AST contains more information and MDNodes contain all the necessary information for Dwarf</div>
<div><br></div><div>I would like to propose the following:</div><div>Step 1: When we are creating the MD nodes, we can provide a simple identifier that is unique within the DIBuider.</div><div> In DIBuilder, implement generateTypeIdentifier for types that are globally visible (one possibility is the type name appended with a unique ID)</div>
<div>Step 2: In DIBuilder::finalize(), we call hashing algorithm to update the type identifiers generated in step 1 to be the type name appended with its hash</div><div><div>Step 1 is necessary because we want to make sure we are using the type identifiers when referring to the types.</div>
<div>Without step 1, the type reference will be via MDNode, and a MDNode field can't be updated to a type identifier later on.</div><div>Step 3: We can then use the folding set to do the uniquing across CUs, during linking.<br>
</div></div><div><br></div><div>Let me know your thoughts,</div><div><br></div><div>Thanks,</div><div>Manman</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
-eric<br>
</font></span></blockquote></div><br></div></div>