IRGen: improve DLLStorage computation for Windows

[compnerd]

This slightly regresses the standard library build (intentionally) while
generally improving the build of dispatch, foundation, xctest.

Rather than continuing to rely on the short-term hack of special casing
the standard library, identify the module where the decl originates
from. If the module is the current module, then assume that the symbol
need not be imported (static linking does not currently work on Windows
anyways). This allows for properly identifying the module where the
symbol will be homed.

Because we no longer special case the standard library here, a few known
metadata types will be incorrectly marked as being imported rather than
local.

Since linked entities which have Shared SILLinkage should be module
local, special case them to always be local. Without this the metadata
access function is still marked incorrectly.

With this computation we now get nearly all the cases correct. Dispatch
no longer has to rely on the linker relaxing the import to a local
binding. XCTest is also clean. Foundation misses the following case:

• $sSS10FoundationE19_bridgeToObjectiveCAA8NSStringCyF

The regressed cases in swiftCore are:

• $sBi64_WV
• $sBi8_WV
• $sBi16_WV
• $sBi32_WV
• $sBpWV
• $syycWV
• $sBoWV
• $sBOWV
• $sBbWV
• $sytWV

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

[compnerd]

@swift-ci please clean test

[compnerd]

@swift-ci please test Windows platform

[compnerd]

CC: @slavapestov @rjmccall @jckarter

[compnerd]

The Windows JIT regression is known and is not caused by this PR (discussion in #29863).

[jckarter]

Nice! Could we also use this to further tighten the accuracy of when getAddrOfLLVMVariableOrGOTEquivalent produces a direct relative reference?

The $s*WV symbols indicate we might be missing a check for value witness tables that refer to structural types from within the standard library.

[compnerd]

@jckarter hmm, yes, we should be able to do that (though I believe it is outside the scope of this change). Yes, the structural VWT references need to be special cased in the standard library. I'll poke around once more, but, I think that this is a significant leap forward in the accuracy for most libraries and is valuable enough as is, assuming that I didn't miss some silly case and/or have some other error.

[jckarter]

I agree!

[compnerd]

Re-reading your comment, I think that I misunderstood what you had said. The VWT references there are regressions for the standard library. That is we get them computed incorrectly for the standard library.

This is an intentional regression in the sense that I know clearly where that has been regressed: https://github.com/apple/swift/pull/30292/files#diff-62e4305d226cedd49d95b3dff4f8b7b8L1845-L1846 would previously simply state that the reference is local for the standard library. Now, we no longer special case the standard library.

My desire is to completely remove the special case tracking of the standard library which is ... less than desired. Unfortunately, at the time, it was the most expedient thing to do, and now one must pay down their debts.

Having looked at this once more, I now can explain why the VWT issue exists. The getDeclContextForEmission for VWTs is not available. The result is that we cannot tell that they are meant to be part of the standard library or not. This is slightly unfortunate, but, I think that we should merge this and then try to incrementally improve the accuracy.

[jckarter]

Thanks for digging deeper. I agree we should minimize special case behavior for the standard library. To me, it seems like it'd be reasonable to have getDeclContextForEmission return the stdlib module as the decl context for structural type value witness tables, since they live in the runtime so are always linked into the standard library today. I'm fine with that happening in another commit after you land this.