In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
Some metadata may require instantiation, but not in a way that requires us to put an additional
cache layer in front of it. `Self` metadata is also trivial to access from the local cache, but
isn't statically referenceable. Split these concepts and update code to use one or the other
appropriately. This catches an issue with metadata prespecialization where it would try to
make records for dynamic `Self` incorrectly.
Regardless of any flags, the stdlib will have its generic metadata
prespecialized.
Temporarily reintroduced the flag to enable the feature flag while
preserving the flag to disable it and changed the default back to off
for the moment.
Temporarily disable metadata prespecialization on platforms other than
MacOS, iOS, tvOS, watchOS, or Linux. At the moment, tests are failing
on Windows with linker errors such as
demangleToMetadata-558ea9.o : error LNK2001: unresolved external symbol $ss5Int64VN
demangleToMetadata-558ea9.o : error LNK2001: unresolved external symbol $sSSSHsWP
Once the issue leading to those linker errors has been resolved, the
feature will be enabled on Windows.
Previously, some ad hoc checks were done in order to determine whether
the metadata access for a generic type was trivial. Now, standard
predicates are used, specifically IRGenModule's member functions
isDependentConformance and isResilientConformance.