[SILVerifier] UnmanagedToRef and RefToUnmanaged must be loadable

[davezarzycki]

In #16237, @rjmccall wrote: "Unmanaged is never not loadable. It's possible that we're messing that up somewhere."

Let's add a SIL verifier and sort this out.

[davezarzycki]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 0ab281df216cec4aa7e14e9a03a98ed5eb262177

[davezarzycki]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 0ab281df216cec4aa7e14e9a03a98ed5eb262177

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 0ab281df216cec4aa7e14e9a03a98ed5eb262177

[davezarzycki]

Hey @rjmccall – Here is an example build failure when SIL verifies Unmanaged loadability:

SIL verification failed: unmanaged_to_ref requires unowned type to be loadable: operandType->isLoadable(ResilienceExpansion::Maximal)
Verifying instruction:
     %2 = struct_extract %0 : $Unmanaged<Instance>, #Unmanaged._value // user: %3
->   %3 = unmanaged_to_ref %2 : $@sil_unmanaged Instance to $Instance // user: %4
     %4 = copy_value %3 : $Instance               // user: %5
In function:
// Unmanaged._value.getter
sil [transparent] [serialized] @$Ss9UnmanagedV6_valuexXuvg : $@convention(method) <Instance where Instance : AnyObject> (Unmanaged<Instance>) -> @owned Instance {
// %0                                             // users: %2, %1
bb0(%0 : @trivial $Unmanaged<Instance>):
  debug_value %0 : $Unmanaged<Instance>, let, name "self", argno 1 // id: %1
  %2 = struct_extract %0 : $Unmanaged<Instance>, #Unmanaged._value // user: %3
  %3 = unmanaged_to_ref %2 : $@sil_unmanaged Instance to $Instance // user: %4
  %4 = copy_value %3 : $Instance                  // user: %5
  return %4 : $Instance                           // id: %5
} // end sil function '$Ss9UnmanagedV6_valuexXuvg'

[rjmccall]

That's because the isLoadable method that you've added in this patch is implemented incorrectly.

I think we're talking past each other. WeakStorageType is never loadable, UnmanagedStorageType is always loadable, and UnownedStorageType is loadable only when the referent type uses native reference counting.

[davezarzycki]

Hi @rjmccall – Thanks. I agree that we're talking past each other. I just don't feel like I fully appreciate what "loadable" means in this context, and I don't appreciate why the referent being native or not would change load-ability.

Does "loadable" refer to reading the reference pointer from memory? If so, then why does the referent nativeness matter? It clearly doesn't matter for Unmanaged, so what is different about Unowned?

Does this have anything to do with magic ObjC pointers that aren't actually pointers (inline object storage, the non-ponter ISA, etc)?

[rjmccall]

"Loadable" means, essentially, that it's semantically okay to load a value of the type into registers — i.e. that it's not tied to being in memory and can safely be moved around with things like memcpy.

• Weak references aren't loadable because we register the storage address with the runtime.
• Unowned references are loadable when they're to native Swift objects because we just increment/decrement the weak reference count, but if they might be Objective-C objects they're no longer loadable because the implementation may have to reserve something with the ObjC runtime in order to perform the checking.
• Unmanaged references are raw pointers that we don't reference-count and so can be freely copied around.

[davezarzycki]

Would "isMovable" or "isCopyable" be a better name then? It feels confusing to have isLoadable() == false generate LoadUnownedInst and friends.

[rjmccall]

No, because those types are still movable and copyable; they just can't be moved with memcpy. Also, "loadable" is a pretty inextricable term of art in the compiler at this point.

[davezarzycki]

Thanks for the feedback John. I think I get it now. I'll have to think about how to add this extra dimension of complexity to #16237.