[SIL] Accesses to globals are deinit barriers.

[nate-chandler]

Accesses to globals which can be used externally (e.g. errno being written to elsewhere) can't be reordered with deinits since deinits could read such globals.

rdar://98542123

[atrick]

We don't need to be so pessimistic about all globals. We generally want to optimize globals that are internal to the module.

We at least need to conservatively handle globals defined outside the module. This will cover the important errno case. In that case, a deinit makes a system call, and we want to make sure we don't run that deinit before some other code that reads errno. In general, the deinit barrier is trying to account for "externally visible side effects". To be true to the spirit of the barrier, we could be a little more conservative and avoid reordering a deinit with any externally visible global:

storage.getGlobal().isPossiblyUsedExternally()?

[nate-chandler]

Added check for possible external use and test case.

[nate-chandler]

@swift-ci please test

[nate-chandler]

@swift-ci please benchmark

[atrick]

After discussing this and realizing there's no real obvious distinction between "external" globals and globals in general, I'm fine just being pessimistic in the presence of any global variable access. (Hopefully we'll be able to stop treating top-level variables as globals soon.)

[nate-chandler]

@swift-ci please test

[nate-chandler]

Removed check for external use and modified test case; changed variable name isInteresting -> retval.

[atrick]

👍