Is passing -Clink-dead-code by default still a good idea? #391
Description
I work on the monomorphization code in the compiler a fair bit, and any use of -Clink-dead-code makes me uncomfortable because that flag isn't just about linkage, it has to toggle off other dead code pruning mechanisms in the compiler in order to produce all the dead code. And many of those code paths that it exercises are not well-tested and certainly are not well-exercised in production use-cases.
cargo-fuzz has run into two ICEs that I know of as a result of using this flag:
rust-lang/rust#135515
#323
(both of these are bugs in the compiler that wouldn't be hit without -Clink-dead-code)
The LLVM issue that motivated using -Clink-dead-code when also using coverage instrumentation is llvm/llvm-project#33984, and it has been closed for years now. It sounds like this is fully fixed with LLD which is the default on nightly toolchains, but not on stable.
Someone should check if GNU's linker still causes trouble if used with --strip-dead-code.
It looks like in some builds, -Clink-dead-code can have a dramatic impact on disk space: bytecodealliance/wasmtime#3875 which might be another motivation for swapping the default behavior of cargo-fuzz.