Under VFE/WME, disable mangled accessors and disable LLVM MergeFunctions

[kubamracek]

Two fixes for problems under VFE/WME/CRR (Virtual Function Elimination, Witness Method Elimination, Conditional Runtime Records):

1. Using type metadata accessors that use mangled name to reference types is problematic, because that hides a dependency/reference to the type from the compiler, as it's only a string-based runtime lookup. Let's disable mangled name accessors under WME/VFE/CRR.

2. When using VFE/WME, calls that go via vtables/wtables are using the @llvm.type.checked.load intrinsic to make a load from the vtable/wtable and pass a string metadata as the type identifier. However, MergeFunctions doesn't account for the type identifier when deciding whether functions are equal -- this very likely warrants a bugfix in LLVM, but until it's ready, let's disable LLVM's MergeFunctions pass when VFE/WME is on.

[kubamracek]

@swift-ci please test

[slavapestov]

Symbolic references in mangled names should still be visible to the linker -- should we instead switch to using symbolic references even for cross-module references instead? Mangled names are a lot more compact than open-coded metadata access functions. CC @jckarter

[jckarter]

I agree, if you're seeing missed references from symbolic references, we should fix that problem instead of disabling them. One class of things that is probably still invisible to mangled names, at least until @al45tair is finished with protocol conformance demangling. A technique we'd discussed to deal with issues like this, is to append artificial references to those runtime entities after the null terminator for the runtime-interpreted part of the mangled name, so e.g. if you have something like Dictionary<Foo, Bar> we'd emit the mangled name with a reference to the Foo: Hashable conformance descriptor after the null terminator.

[kubamracek]

Agree that fixing the missing references from mangled references is the right solution, and I'll work on that. I would still like to propose to temporarily go forward with this change, as a temporary solution to unblock actually using VFE/WME. This PR fixes the only remaining blockers from using VFE/WME on the 'freestanding' stdlib build, and I'd argue that getting this configuration in place has immediate benefits (CI will start testing it so it won't regress).

Given that, I'm happy to sign up to actually fix the missing references, but I'd like to do that as a follow-up (very soon, let's plan for next week or so). Would that be acceptable, @jckarter, @slavapestov?

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test Windows platform

[kubamracek]

Fixing LLVM MergeFunctions in https://reviews.llvm.org/D112870.

[eeckstein]

@kubamracek I believe you also have to disable the swift merge function pass (see createSwiftMergeFunctionsPass)