-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
codegen-llvm: never combine DSOLocal and DllImport #104679
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
Could you add a |
Yeah, it would be nice to try reverting #101413 when this is merged. |
I now added I would like to also add foreign linkage to this test, but currently all declarations are marked |
@rustbot ready |
Apparently yes, and it's a relatively recent change (#83592), but I didn't participate in that work and not sure whether the case you mention was considered. |
@bors r+ rollup=iffy |
codegen-llvm: never combine DSOLocal and DllImport Prevent DllImport from being attached to DSOLocal definitions in the LLVM IR. The combination makes no sense, since definitions local to the compilation unit will never be imported from external objects. Additionally, LLVM will refuse the IR if it encounters the combination (introduced in [1]): ``` if (GV.hasDLLImportStorageClass()) Assert(!GV.isDSOLocal(), "GlobalValue with DLLImport Storage is dso_local!", &GV); ``` Right now, codegen-llvm will only apply DllImport to constants and rely on call-stubs for functions. Hence, we simply extend the codegen of constants to skip DllImport for any local definitions. This was discovered when switching the EFI targets to the static relocation model [2]. With this fixed, we can start another attempt at this. [1] https://smlnj-gitlab.cs.uchicago.edu/manticore/llvm/commit/509132b368efed10bbdad825403f45e9cf1d6e38 [2] rust-lang#101656
codegen-llvm: never combine DSOLocal and DllImport Prevent DllImport from being attached to DSOLocal definitions in the LLVM IR. The combination makes no sense, since definitions local to the compilation unit will never be imported from external objects. Additionally, LLVM will refuse the IR if it encounters the combination (introduced in [1]): ``` if (GV.hasDLLImportStorageClass()) Assert(!GV.isDSOLocal(), "GlobalValue with DLLImport Storage is dso_local!", &GV); ``` Right now, codegen-llvm will only apply DllImport to constants and rely on call-stubs for functions. Hence, we simply extend the codegen of constants to skip DllImport for any local definitions. This was discovered when switching the EFI targets to the static relocation model [2]. With this fixed, we can start another attempt at this. [1] https://smlnj-gitlab.cs.uchicago.edu/manticore/llvm/commit/509132b368efed10bbdad825403f45e9cf1d6e38 [2] rust-lang#101656
Prevent DllImport from being attached to DSOLocal definitions in the LLVM IR. The combination makes no sense, since definitions local to the compilation unit will never be imported from external objects. Additionally, LLVM will refuse the IR if it encounters the combination (introduced in [1]): if (GV.hasDLLImportStorageClass()) Assert(!GV.isDSOLocal(), "GlobalValue with DLLImport Storage is dso_local!", &GV); Right now, codegen-llvm will only apply DllImport to constants and rely on call-stubs for functions. Hence, we simply extend the codegen of constants to skip DllImport for any local definitions. This was discovered when switching the EFI targets to the static relocation model [2]. With this fixed, we can start another attempt at this. [1] https://smlnj-gitlab.cs.uchicago.edu/manticore/llvm/commit/509132b368efed10bbdad825403f45e9cf1d6e38 [2] rust-lang#101656
Add a codegen-test that verifies inter-crate linkage with the static relocation model. We expect all symbols that are part of a rust compilation to end up in the same DSO, thus we expect `dso_local` annotations.
CI failed for MacOS, because there the I accidentally also rebased on master, sorry for that! The only change from before is @rustbot ready |
@bors r+ |
How about |
Yeah, I thought about this as well, but as I mentioned I expect other targets to possibly have the same shortcuts in the Additionally, I would like to test for |
☀️ Test successful - checks-actions |
Finished benchmarking commit (8de4b13): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
Seems more like Windows specific (so could be also tested on
If you think it would be beneficial... |
Prevent DllImport from being attached to DSOLocal definitions in the LLVM IR. The combination makes no sense, since definitions local to the compilation unit will never be imported from external objects.
Additionally, LLVM will refuse the IR if it encounters the combination (introduced in [1]):
Right now, codegen-llvm will only apply DllImport to constants and rely on call-stubs for functions. Hence, we simply extend the codegen of constants to skip DllImport for any local definitions.
This was discovered when switching the EFI targets to the static relocation model [2]. With this fixed, we can start another attempt at this.
[1] https://smlnj-gitlab.cs.uchicago.edu/manticore/llvm/commit/509132b368efed10bbdad825403f45e9cf1d6e38
[2] #101656