<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 9, 2014 at 6:44 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The attached patch makes clang use comdats for linkonce_odr structors.<br>
This matches the gcc behavior and there are two potential advantages<br>
that I can think off<br>
<br>
* Avoid a bit of code bloat when mixing gcc and clang compiled code<br>
since they will have the same COMDATs.<br></blockquote><div><br></div><div>Can you say a bit more about the cases where this reduces code bloat? Either way, we'll end up with exactly one definition of each Dn variant that is used, won't we?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Avoid pain to users that developed a dependency on the gcc behavior,<br>
but it might be a bit late for that<br>
(<a href="http://llvm.org/devmtg/2014-04/PDFs/Talks/NickRefactoring.pdf" target="_blank">http://llvm.org/devmtg/2014-04/PDFs/Talks/NickRefactoring.pdf</a>).<br></blockquote><div><br></div><div>I don't think making broken code work better has a lot of value; I think it's better to focus our efforts on making it easier to detect that code is broken.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was hoping this wouldn't have a noticeable code quality impact, but<br>
I have seen at least two issues<br>
<br>
* Putting D0 in the D5 comdat is an ABI bug IMHO since it is never<br>
equal to D1 or D2 and doing so with linkonce_odr can bloat the code a<br>
bit by causing us to keep more functions then we need (keep D1/D2 if<br>
they get inlined into D0 for example).<br></blockquote><div><br></div><div>It will cause us to emit more IR, but I don't see that it will cause us to keep more functions; the D0 will still be discardable if it ends up unused, right? (It looks like GNU ld's --gc-sections will keep sections that are within a used COMDAT, but gold's --gc-sections will remove them.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Using a COMDAT for the destructors of a class bar prevents D2 from<br>
being replaced with D2 of the base class. That means we end up with<br>
<br>
define linkonce_odr void @_ZN3fooIiED2Ev(%struct.foo* %this)<br>
unnamed_addr #1 comdat $_ZN3fooIiED5Ev align 2 {<br>
entry:<br>
  %0 = bitcast %struct.foo* %this to %struct.bar*<br>
  tail call void @_ZN3barD2Ev(%struct.bar* %0)<br>
  ret void<br>
}<br>
<br>
Instead of rauw of _ZN3fooIiED2Ev with _ZN3barD2Ev. We could teach<br>
LLVM to do this, but we are not there yet.<br></blockquote><div><br></div><div>I think you can still RAUW; you just need to leave the derived dtor behind if you leave any part of its comdat behind.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So it is not clear if this is worth it having it upstream. What do you<br>
guys think?</blockquote><div><br></div><div>Not sure yet.</div></div></div></div>