Incredibly breaking, and hopefully future-proof changes!
Two major changes are included:
CLI interface proposal,
Foundation for further development.
CLI
With upcoming rustc NVPTX-related changes, we have a chance to implement a proper "communication interface" with the linker. Legacy CLI was a hack to extract important information out of ld-like calling convention. For the more maintainable and clear solution, we are going to create own simplified ptx-linker linker-flavour on rustc-side. No more ambiguous and useless flags!
Also, now there is a way to control output type and CUDA arch via CLI!
For example, rustc -Clink-arg=--emit=ptx,llvm-ir will emit both PTX assembly and final LLVM IR. Or rustc -Clink-arg=--arch=sm_60 to set sm_60 as the target arch.
Eventually, there will be a chance to output cubin (not yet supported) with several architectures:
rustc -Clink-arg=--arch=sm_20,sm_60 -Clink-arg=--emit=cubin
It is possible to specify the linker flags permanently for a crate with .cargo/config.
For backward compatibility, legacy binaries were renamed to legacy-ptx-linker and legacy-rustc-dylib-wrapper. Relevant naming changes will be applied to ptx-builder after the 0.9 will be published.
Further development
There are also changes to control whether legacy CLI or rustc-llvm-proxy should be enabled. By default, both new and legacy binaries are built and with enabled LLVM proxying. I hope, eventually we will be able to build the linker during the Rust build process, and therefore we will be able to get rid of obsolete legacy binaries and hacky LLVM proxying.
What's next?
0.9 is not yet ready, unfortunately. Before publishing I would like to increase code quality by addressing clippy issues, implementing error handling without error_chain and more minor refactoring.
Incredibly breaking, and hopefully future-proof changes!
Two major changes are included:
CLI
With upcoming
rustcNVPTX-related changes, we have a chance to implement a proper "communication interface" with the linker. Legacy CLI was a hack to extract important information out ofld-like calling convention. For the more maintainable and clear solution, we are going to create own simplifiedptx-linkerlinker-flavour onrustc-side. No more ambiguous and useless flags!Also, now there is a way to control output type and CUDA arch via CLI! For example,
rustc -Clink-arg=--emit=ptx,llvm-irwill emit both PTX assembly and final LLVM IR. Orrustc -Clink-arg=--arch=sm_60to setsm_60as the target arch.Eventually, there will be a chance to output cubin (not yet supported) with several architectures:
rustc -Clink-arg=--arch=sm_20,sm_60 -Clink-arg=--emit=cubinIt is possible to specify the linker flags permanently for a crate with
.cargo/config.For backward compatibility, legacy binaries were renamed to
legacy-ptx-linkerandlegacy-rustc-dylib-wrapper. Relevant naming changes will be applied toptx-builderafter the 0.9 will be published.Further development
There are also changes to control whether legacy CLI or
rustc-llvm-proxyshould be enabled. By default, both new and legacy binaries are built and with enabled LLVM proxying. I hope, eventually we will be able to build the linker during the Rust build process, and therefore we will be able to get rid of obsolete legacy binaries and hacky LLVM proxying.What's next?
0.9 is not yet ready, unfortunately. Before publishing I would like to increase code quality by addressing clippy issues, implementing error handling without
error_chainand more minor refactoring.cc @rust-cuda