<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 1, 2016 at 10:16 AM, Robinson, Paul <span dir="ltr"><<a href="mailto:paul.robinson@sony.com" target="_blank">paul.robinson@sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-6354707677066198018WordSection1"><span class="gmail-">
<p class="MsoNormal">The largest discriminator is 779 (coming from 471.omnetpp, which has significant amount of EH code.)<span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><a name="m_-6354707677066198018__MailEndCompose"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></a></p>
</span><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">779 distinct blocks coming from a single source location?  That's astounding.</span></p></div></div></blockquote><div><br></div><div>Agree, but that's a rare case. All code in landing pads for a super large function LargeNet::doBuildInside are mapped to the same line (end of the function). So we end up assigning new discriminators for each one of them.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-6354707677066198018WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><span class="gmail-">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal">Or something like:<u></u><u></u></p>
<p class="MsoNormal">high bits   ---------->  low bits<u></u><u></u></p>
<p class="MsoNormal">EEEEEEEECCCCCFFDDD CFFFDDD CCFFFDD<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">So the lower 7 bits should be able to cover 85% percentile and the lower 14 bits should be able to cover 99% percentile.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Having a scheme for compact representation for the vast majority of cases is great, and will really help keep the size of the section under control.  Did you
 have a plan for the degenerate cases where one of these elements (D/F/C) exceeds the specified capacity?  You already have one, because 779 > 8 bits.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Thanks,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">--paulr<u></u><u></u></span></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>

</blockquote></div><br></div><div class="gmail_extra">That's right, we still have 8 empty bits. Maybe we can extend  D to 10 bits. We can also set a cap to D, F and C.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Dehao</div></div>