IRGen: initial pass to support async inheritance on Windows

[compnerd]

With PE/COFF, one cannot reference a data symbol directly across the
binary module boundary. Instead, the reference must be indirected
through the Import Address Table (IAT) to allow for position
independence.

When generating a reference to a AsyncFunctionPointer ({i8*, i32}), we
tag the pointer as being indirected by tagging bit 1 (with the
assumption that native alignment will ensure 4/8 byte alignment, freeing
the bottom 2 bits at least for bit-packing). We tweak the
v-table/witness table emission such that all references to the
AsyncFunctionPointer are replaced with the linker synthetic import
symbol with the bit packing:

.quad __imp_$s1L1CC1yyYaKFTu+1

rather than

.quad $s1L1CC1yyYaKFTu

Upon access of the async function pointer reference, we open-code the
check for the following:

pointer = (pointer & 1) ? *(void **)(pointer & ~1) : pointer;

Thanks to @DougGregor for the discussion and the suggestion for the
pointer tagging. Thanks to @aschwaighofer for pointers to the code that
I had missed. Also, thanks to @SeanROlszewski for the original code
sample that led to the reduced test case.

Fixes: SR-15399

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 test Windows platform

[compnerd]

CC: @DougGregor @aschwaighofer

[aschwaighofer]

I looked over the uses of getAddrOfAsyncFunctionPointer and my first take was: wait a minuted don't we need to update RelativeDirectPointer uses in runtime structures to RelativeIndirectablePointer. But then I realized that code generation will take care of resolving the indirection (if the lower bit is set).

i.e. I think it is fine to leave the code below as a target relative direct pointer because what will happen is that we will "copy" the indirect pointer (after resolving the relative computation) during the initClassVTable computation and any use of that indirect pointer is going to be handled by codegen (just as we would for the static vtable we emit for regular classes).

template <typename Runtime>                                                     
struct TargetMethodDescriptor {                                                 
  /// Flags describing the method.                                              
  MethodDescriptorFlags Flags;                                                  
                                                                                
  /// The method implementation.                                                
  TargetRelativeDirectPointer<Runtime, void> Impl; // <= On windows is this an indirectable pointer? I think the answer is no.
                                                                                
  // TODO: add method types or anything else needed for reflection.             
}; 

static void initClassVTable(ClassMetadata *self) {                              
  const auto *description = self->getDescription();                             
  auto *classWords = reinterpret_cast<void **>(self);                           
                                                                                
  if (description->hasVTable()) {                                               
    auto *vtable = description->getVTableDescriptor();                          
    auto vtableOffset = vtable->getVTableOffset(description);                   
    auto descriptors = description->getMethodDescriptors();                     
    for (unsigned i = 0, e = vtable->VTableSize; i < e; ++i) {                  
      auto &methodDescription = descriptors[i];                                 
      swift_ptrauth_init_code_or_data(                                          
          &classWords[vtableOffset + i], methodDescription.Impl.get(),  // <== Here        
          methodDescription.Flags.getExtraDiscriminator(),                      
          !methodDescription.Flags.isAsync());                                  
    }                                                                           
  } 

[aschwaighofer]

lgtm

[compnerd]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 68bc33f

[compnerd]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - fee023c

[compnerd]

@swift-ci please test Linux platform

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - fee023c

[compnerd]

@swift-ci please clean test Linux platform

[briancroom]

Great to see this addressed already. Thank you for driving the fix, @compnerd!