<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 30, 2016 at 8:07 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">dexonsmith added a subscriber: dexonsmith.<br>
dexonsmith added a comment.<br>
<span class="gmail-"><br>
You never answered my question from a few weeks ago:<br>
<br>
> Every 8 bytes counts for a lot since we have so many of these in LTO.  If we can find some way to make it optional (via subclassing?) that would be great.<br></span></blockquote><div><br></div><div>I missed your comment, and my reply from last week never hit the list, so let's write it again.</div><div><br></div><div>---</div><div><br></div><div>Are you suggesting we have a DIMSSubprogram, or a DIVirtualMethod? <span style="font-size:12.8px">We could have a DIVirtualMethod that contains Virtuality, VirtualIndex, and ThisAdjustment. It's still a net space increase for 64-bit because it won't shrink sizeof(DISubprogram) and we will still be wasting memory for ThisAdjustment for non-MS virtual methods.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I don't really want to have DIMSVirtualMethod or DIMSSubprogram, I feel like that will make our debug IR more divergent, not less. Do you think the memory savings is worth the complexity?</span></div><div style="font-size:12.8px"><br></div><div><span style="font-size:12.8px">I'm hesitant to start making subclasses on my own without understanding where you really want to go with the subprogram declaration / definition split. Maybe we can chat about this later tonight, if you're going to the social.</span></div></div></div></div>