Prevent "Target-incompatible DataLayout" LLVM asserts.

[eddyb]

Example of such an assertion:
Assertion 'TM.isCompatibleDataLayout(getDataLayout()) && "Can't create a MachineFunction using a Module with a " "Target-incompatible DataLayout attached\n"' failed.

It appears that since LLVM 3.7, DataLayout is checked for target compatibility, and as joker-eph on LLVM's IRC channel on OFTC explains:

technically a Target can implement a "compatibility check" if it is willing to relax the constrain that the DL matches, but we haven't implemented anything like that that I know of. So the backend check if the Module data layout is the same as what the target wants.

The relevant method is bool TargetMachine::isCompatibleDataLayout(const DataLayout &Candidate).

joker-eph suggests warning and overriding an incompatible data layout with the target default.
However, I don't think we can do anything but error because we would've already used the (incompatible) data layout string for determining type layouts.

We can at least provide the target default data layout string for the user in that situation.
cc @alexcrichton

[nagisa]

Perhaps we should also check that the target with the mismatching datalayout is not built-in and if it is, emit an ICE.

[eddyb]

@nagisa There's already a check that the built-in datalayouts are identical to the target defaults.

[alexcrichton]

If this is the case, should we just go back to picking it up from LLVM by default, but allowing a specification for a custom one?

[eddyb]

@alexcrichton If we want to build a WASM backend, for example, how could that work without linking LLVM? Do we want to couple target specifications to LLVM in such a way that you need special ones for non-LLVM backends?

[alexcrichton]

Hm perhaps, yeah. This is kinda just an area where custom target specs aren't exactly intended to be stabilized as how would a wasm backend read and use a custom target spec anyway?

[eddyb]

@alexcrichton If you use the driver it's all automated.
In a way, it doesn't make sense to have target specs for a wasm backend, there's one wasm "target spec".

What do you think about having librustc_driver pass some librustc_trans validator/elaborator to librustc_back?
This would alleviate the need for several options which are currently mandatory, if "llvm-target" is present, as they can be extracted from that by querying LLVM itself.

I would keep all the information for the built-in targets there, just so we can get alerted if anything doesn't match the LLVM defaults for that specific triple, but target specs would have no guarantees of compatibility across LLVM versions.

To get back to wasm: it could have a target spec that doesn't contain "llvm-target", so that you can't actually use the LLVM backend with it, but it includes all information needed to otherwise run all analysis passes.

[alexcrichton]

Sounds plausible to me!

[Mark-Simulacrum]

From #34960:

Discovered in #34743, LLVM's data layouts are changing over time. If we assert that our own data layout agrees with LLVM's then if we change to a newer LLVM we break compatibility with older LLVMs. It looks like the change to the data layout was backwards compatible, I think, so we probably just need a different check here.

[steveklabnik]

Triage: not aware of any changes.