-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Remove deps_info system and the running of llvm-nm on input files. NFC #18905
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Split out from #18905, which completely removes llvm_nm_multiple.
Also use the `weak` macros from musl's internal features.h Split out from #18905
Split out from #18905, which completely removes llvm_nm_multiple.
Also use the `weak` macros from musl's internal features.h Split out from #18905
Split out from #18905, which completely removes llvm_nm_multiple.
Also use the `weak` macros from musl's internal features.h Split out from emscripten-core#18905
…18908) Split out from emscripten-core#18905, which completely removes llvm_nm_multiple.
Also use the `weak` macros from musl's internal features.h Split out from emscripten-core#18905
…18908) Split out from emscripten-core#18905, which completely removes llvm_nm_multiple.
8147f9b
to
e7b2986
Compare
99a521d
to
194e399
Compare
0d552d5
to
1192eb0
Compare
67c9142
to
a1cfdc7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What impact does this have on link times?
133cdf6
to
1d0b596
Compare
if basename in {'vmlock.o'}: | ||
return 'AAA_' + basename | ||
else: | ||
return basename |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So IIUC, __vm_wait
is defined in vmlock
properly, and in a weak form by mmap
. If mmap appears first then the weak form is linked in. It will be overwritten by the non-weak vmlock
version later, so the code will work, but meanwhile it pulled in all of the mmap
file, which adds some overhead. Is that right?
Is there no linker option to make them look forward for a non-weak version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats exactly right yes. I confirmed this behaviour using native gcc and clang too. The first symbol that is found will be used. Only later when the object file containing the strong definition is included for some other reason will the strong definition overwrite the weak one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we avoid this code then by splitting up mmap.c
into two files? Then mmap__vm_wait
would just contain the __vm_wait
for mmap
, and linking it in wouldn't bring in all of mmap
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there might be another way to do it such as the one you suggest. But mmap.c
is an upstream musl file so splitting it up for this reason seem hacky and harder to maintain over time. This hack doesn't seem any worse to me.
Also, I think over time we might find other files to add to this list for similar reasons since musl makes quick heavy use of weak linking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, sgtm.
The timing results for binaryen linked with Before:
After:
Thats an average of 1.688 and 1.357 which is a speedup of 20%! |
Nice speedup! |
if basename in {'vmlock.o'}: | ||
return 'AAA_' + basename | ||
else: | ||
return basename |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we avoid this code then by splitting up mmap.c
into two files? Then mmap__vm_wait
would just contain the __vm_wait
for mmap
, and linking it in wouldn't bring in all of mmap
?
5f2df2d
to
914f693
Compare
Added ChangeLog entry. |
a4fb164
to
3ebaf30
Compare
… NFC This uses a new "stub object" construct to tell the linker (wasm-ld) not only about the existence of the JS library symbols but the native symbols on which they depend (a.k.a reverse dependencies). This allows us to completely remove deps_info.py in favor of just using normal `__deps` entries in the library files. It also means we no longer need to run `llvm-nm` on the linker inputs to discover the symbols they use. Depends on: https://reviews.llvm.org/D145308 Fixes: #18875
…cies This actually simplifies the code by performs a pre-pass of the stub objects prior to LTO. This should be the final change needed before we can make the switch on the emscripten side: emscripten-core/emscripten#18905 Differential Revision: https://reviews.llvm.org/D148287
…cies This actually simplifies the code by performs a pre-pass of the stub objects prior to LTO. This should be the final change needed before we can make the switch on the emscripten side: emscripten-core/emscripten#18905 Differential Revision: https://reviews.llvm.org/D148287
This uses a new "stub library" construct to tell the linker (https://reviews.llvm.org/D145308) not only about the existence of the JS library symbols but the native symbols on which they depend (a.k.a reverse dependencies).
This allows us to completely remove deps_info.py in favor of just using normal
__deps
entries in the library files. It also means we no longer need to runllvm-nm
on the linker inputs to discover the symbols they use.Fixes: #18875