Cleanup and document -C relocation-model

[petrochenkov]

As the title says, this is mostly a refactoring and documentation.

One potentially observable change here is that -C relocation-model=default now takes the default from the Rust target, rather than from the underlying LLVM target. In other words, -C relocation-model=default is now equivalent to not specifying the relocation model on command line at all.
Apparently no one used that option because it has other bugs as well, e.g. PIC default wasn't treated as PIC in some places.

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[Amanieu]

Could we add some validation to check that a relocation model is valid for a particular target? For example ropi, rwpi, ropi-rwpi are only supported on ARM targets (clang actually validates this before passing it on to LLVM). Also dynamic-no-pic is only support on Darwin targets.

Question: should the choice of relocation model have an impact on the TLS model? For example, if a crate is only going to be used in an executable and not in a shared library then we can use the local-exec TLS model.

[petrochenkov]

@Amanieu

Could we add some validation to check that a relocation model is valid for a particular target? For example ropi, rwpi, ropi-rwpi are only supported on ARM targets (clang actually validates this before passing it on to LLVM). Also dynamic-no-pic is only support on Darwin targets.

Yeah, it would be nice to warn about this, if not error.
Right now rustc behaves more like gcc which silently accepts conflicting options and produces something unspecified, than like clang which tries to produce warnings.
(E.g. in gcc -shared -pie -pie silently wins, but in clang -shared -pie -shared wins with a warning.)

I'm not sure we can emit errors here due to compatibility.
Apparently there's some folklore about dynamic-no-pic being the way to disable -pie, for example.
The special models usually turn into static when enabled for inappropriate targets, so nothing fatal happens in that case.

I've made an issue about this - #71552.

(EDIT: I'll look at the TLS model question a bit later.)

[Amanieu]

I'm more concerned that we are passing relocation models to LLVM on targets that do not support them. These code paths are untested since clang doesn't do this, which is likely to lead to LLVM assert failures down the line.

[davidtwco]

Implementation LGTM, r=me after discussion about validation is resolved.

[petrochenkov]

@Amanieu

Question: should the choice of relocation model have an impact on the TLS model? For example, if a crate is only going to be used in an executable and not in a shared library then we can use the local-exec TLS model.

Looks like LLVM does that automatically, see TargetMachine::getTLSModel, it's enough for us to set the PIE level (which we do).
User (e.g. rustc with -Z tls-model) can only choose a more relaxed model than LLVM does, e.g. local-exec in a shared library, or something like that.

https://github.com/rust-lang/llvm-project/blob/rustc/10.0-2020-02-05/llvm/lib/Target/TargetMachine.cpp#L210-L235

It's not yet clear to me what we need to do for LLVM to set IsLocal to true and relax global-dynamic/initial-exec to local-dynamic/local-exec.

[petrochenkov]

I'm more concerned that we are passing relocation models to LLVM on targets that do not support them. These code paths are untested since clang doesn't do this, which is likely to lead to LLVM assert failures down the line.

I don't disagree, I just think it's better done in a separate PR.

[petrochenkov]

@bors r=davidtwco

[bors]

📌 Commit 45fbe8f has been approved by davidtwco