<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 15, 2015 at 4:55 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jul 15, 2015 at 1:45 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If the file order in command line does't matter, we can read archive files and adding symbols from them concurrently, so even if total amount of work doesn't change, that could still make things faster.</div></blockquote><div><br></div></span><div>--start-group and --end-group I don't think precisely cause COFF-like behavior. IIRC they actually mean "use the same behavior, but circle back around if there is anything unresolved". So it only causes a place which would cause "undefined symbol error" to have the linker keep going.</div></div></div></div></blockquote><div><br></div><div>That's right. COFF behavior is not the same as the case if all files are wrapped with --start-group and --end-group. I'd think we eventually had to implement Unix semantics.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 15, 2015 at 1:35 PM, Joerg Sonnenberger <span dir="ltr"><<a href="mailto:joerg@britannica.bec.de" target="_blank">joerg@britannica.bec.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Jul 14, 2015 at 03:12:04PM -0700, Rui Ueyama wrote:<br>
> On Tue, Jul 14, 2015 at 3:07 PM, Joerg Sonnenberger <<a href="mailto:joerg@netbsd.org" target="_blank">joerg@netbsd.org</a>><br>
> wrote:<br>
><br>
> > joerg added a subscriber: joerg.<br>
> > joerg added a comment.<br>
> ><br>
> > I don't understand how forcing everything to be grouped can make things<br>
> > more efficient, given that it is strictly required to do more work. It<br>
> > doesn't even matter for plain object files, just for libraries. In the case<br>
> > of libraries, there are subtle error cases involving weak symbols, so<br>
> > please do *not* change the resolution algorithm.<br>
> ><br>
><br>
> It's faster because we don't have to visit files grouped by<br>
> --start-group/--end-group repeatedly.<br>
<br>
</span>That statement *still* doesn't make sense. Except maybe glibc's libc.so<br>
hack, I see groups rarely used at all. Certainly not for plain object<br>
files and if anything, only implicitly for library archives. So how can<br>
forcing the *additional* work improve things again?<br>
<br>
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>