<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>> >>><br>
>> >>> Except we'd never actually need to merge the flag - since we would<br>
>> >>> drop<br>
>> >>> it from any module that didn't have the latest, right? I'm not sure<br>
>> >>> this<br>
>> >>> would need to be a module flag, then, since there would be no need to<br>
>> >>> define<br>
>> >>> merging behavior. Is there an advantage to using a module flag over<br>
>> >>> just<br>
>> >>> putting it on the compile unit metadata node somewhere?<br>
>> >><br>
>> >><br>
>> >> Agreed. So we have two choices here, use a module flag and remove the<br>
>> >> module flag when stripping the debug info, so we will never merge<br>
>> >> modules<br>
>> >> with different debug info versions. (no new mode is required)<br>
>> >><br>
>> >> The other choice is putting it on the compile unit MDNode as a field.<br>
>> >> There is no reliable way of checking if an old bc file has a version<br>
>> >> number, because it requires parsing the CU MDNodes in the old bc files.<br>
>> >> Also if we are not going to support multiple debug info versions in a<br>
>> >> single compiler, there is no point of putting a version number in each<br>
>> >> CU<br>
>> >> MDNode.<br>
>> ><br>
>> ><br>
>> > Fair point. Any useful tradeoffs to consider between a single named<br>
>> > MDNode<br>
>> > and a module flag?<br>
>> ><br>
>><br>
>> Probably simplicity at the moment. A module flag is pretty easy to<br>
>> read/parse/etc at load time versus having to put it in the metadata<br>
>> itself.<br>
><br>
><br>
> If the module flag is easier - I'm all for it. I wasn't sure if they were<br>
> schematized more strictly than metadata or anything.<br>
><br>
>><br>
>> In the metadata itself though we'd have everything self<br>
>> contained (i.e. just stick it as a field on the compile unit or<br>
>> something).<br>
><br>
><br>
> I'm with Manman on the "if we never have mismatched versions, paying a<br>
> per-CU overhead is silly" position, so I'd put it in its own named metadata<br>
> instead (since necessarily anything other than the loading code would never<br>
> see CUs with anything other than the current debug version, so it would be<br>
> entirely redundant) - but sounds like module is simpler, so that's great.<br>
><br>
<br>
</div></div>Lots of agreement here. :)</blockquote><div><br></div><div>Great that we reach agreement :)</div><div>I will start adding the module flag and updating the testing cases.</div><div><br></div><div>Thanks,</div>
<div>Manman </div></div></div></div>