<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 4, 2015 at 11:27 AM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">Since the compiler is always free to delete available_externally</span><br></div></div>
functions, I think you could just add a pass to the -flto=thin pipeline<br>
that deletes all of them (referenced or not) -- it's just a single loop<br>
through all the functions deleting the bodies of those with the right<br>
linkage. I imagine there are other pass pipelines that might want to do<br>
something similar. I don't really like having GlobalDCE delete them<br>
(even behind a flag) because they aren't actually dead, and I think a<br>
separate pass makes it easier to test and all that. (I haven't actually<br>
worked much with pass pipelines, though, so there's a chance I'm on my<br>
own here?)<br></blockquote><div><br></div><div>It's possible to get into situations where available_externally functions or globals (dllimported vftable) reference linkonce_odr functions (virtual destructor thunks), so a single pass to drop available_externally function bodies isn't as strong as adding a flag to GlobalDCE.</div><div><br></div><div>Personally, I think the right approach is to add a bool to createGlobalDCEPass defaulting to true named something like IsAfterInlining. In most standard pass pipelines, GlobalDCE runs after inlining for obvious reasons, so the default makes sense. The special case is the LTO pass pipeline, where the code will be reloaded and reoptimized later. IMO it's natural to put the customization there.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You make an interesting point about applying different thresholds to<br>
imported functions, but is there any reason not to change all<br>
available_externally functions in the some way? Moreover, it feels like<br>
thin-LTO's imported functions are a new source of functions with<br>
available_externally linkage, but otherwise they aren't interestingly<br>
different.</blockquote><div><br></div><div>Right, ThinLTO functions and C99 inline functions aren't interestingly different. Having GlobalDCE drop bodies of available_externally functions in the standard -O2 pipeline avoids wasting time running IR passes like CodeGenPrepare on them.</div></div></div></div>