I took a quick stab at this and realized that we don't have some critical bit of information to do this
The problem is that symbols are strongly bound with two-level namespaces on Windows. This means that we need to know the name of the runtime module which we should be binding to (even if weakly) (the import library specifies the runtime name of the module, which may be different - e.g. linking against ucrt.lib introduces a dependency on win-core-stdio-1-1.dll). Symbols cannot be looked up by name as all symbols are tuples of (module, ordinal). Linking by named function is permissible (and recommended), though the loader will resolve the symbol name to ordinal and it is preferable to use the name to avoid ordinal renumbering from incorrect binding.
Even if we restrict this to Swift modules (as we do not have sufficient information for symbols imported through the clang importer), we still face the problem that
-module-link-name can be different values (e.g. libdispatch). If we have the module link name serialized into the swift module and tie that information into the IR somehow, I suppose that we should be able to construct the appropriate constructor.
Also, is my understanding correct that the table approach is to avoid size costs? Emitting a constructor per symbol is possible, but would be expensive in terms of code size.