<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 27, 2015 at 1:06 PM, 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"><span class=""><br>
> On 2015-Jul-21, at 15:35, Xinliang David Li <<a href="mailto:xinliangli@gmail.com">xinliangli@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> This scares me a little for linkonce -- there's a minor change to<br>
> semantics if the importing module would have linked against a<br>
> *different* definition of the same symbol -- but I'm not really<br>
> sure it matters much.<br>
><br>
><br>
><br>
> This should not be an issue in practice as it exists non thinLTO compilations too. For instance changing the optimization level of one module can lead to different inline decisions and different copy of the comdat function to be picked up in the end.<br>
><br>
<br>
</span>Good point.<br>
<span class=""><br>
><br>
> ><br>
><br>
> I wonder whether a prefix would be better?<br>
><br>
> All the promotion/renaming scares me.  I feel like there may be<br>
> dragons here we're not aware of.<br>
><br>
><br>
> The promotion scheme is similar to LIPO which has been exercised on large number of huge C++ apps --  I think it is robust.<br>
<br>
</span>Sure, but other languages, platforms and conventions may yield<br>
other problems.  Anyway, it's just a theoretical concern, I don't<br>
have anything concrete!<br>
<span class=""><br>
><br>
> The only concrete concern I have (once you switch to hidden<br>
> visibility) is the interaction with non-LTO'd objects being linked<br>
> into the same executable, but I wonder if I'm missing something<br>
> else, too...<br>
><br>
><br>
> There is an limitation (also with LIPO, LTO) that you can not compile one module say 'a.c' in thinLTO mode with the rest of the modules, and later recompile 'a.c' into 'a.o' without thinLTO and tries to mix and match with the rest of the real object files built with thinLTO unless 'a.c' is not imported by any other modules or it does not have any statics to be promoted.<br>
<br>
</span>Interesting.  I don't think LTO has this limitation.  But I also<br>
don't think this is too important; if someone turns off thin-LTO for<br>
a particular object file, the build system should detect that the<br>
object changed and regenerate all the things that depend on it, so<br>
there's no correctness problem here; and it seems like a rare thing<br>
to toggle, so I can't see this really causing a concern for compile<br>
time.</blockquote><div><br></div><div>Its main usage I can see is for bug triaging (using object mix&match) -- there are other ways to do that. For instance 1) add option to force static promotion for O2 or selectively disabling importing etc. So right, it is only a concern on paper.</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div><br></div><div> </div></div><br></div></div>