IRGen: fast casting to final classes

[eeckstein]

When casting a class instance to a final class, we can directly compare the isa-pointer with address of the metadata.
This avoids a call to swift_dynamicCastClass.
It also avoids a call to the metadata accessor of the class (which calls swift_getInitializedObjCClass).
For comparing the metadata pointers it's not required that the metadata is fully initialized.

It results in a significant performance improvement for class-casting intensive code. I measured 30% speedup for the new stack promotion + escape analysis, where we do a lot of dynamic instruction casting (#39438).

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[mikeash]

Does emitHeapMetadataRefForHeapObject handle non-pointer isa and artificial subclasses?

[eeckstein]

As discussed offline, ObjectiveC classes are excluded from this optimization anyway

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci benchmark

[tbkka]

This looks like it should apply to is tests as well?

[atrick]

@tbkka When this exact check fails, do we then also need to check that the source's type is not __SwiftValue? If it is, then a dynamic call is needed to bridge to the final class.

Trying to answer my question: as long as this code is only reached when the static type of the cast's source is a class, then the dynamic type cannot be __SwiftValue. The static type of __SwiftValue is always a protocol.

@eeckstein this optimization only happens when the source's static type is a class right?

[eeckstein]

This looks like it should apply to is tests as well?

is is done with the same SIL instruction as as: check_cast_br. So, yes, it applies to is as well

[eeckstein]

this optimization only happens when the source's static type is a class right?

class or class existential, but not AnyObject

[atrick]

It turns out that casting an existential to a class may return a different object than the source of the cast. Once we fix CheckedCastInst::directlyForwarding, this case will be pessimized:

func castProtocolToFinal(_ p: Classes.P) -> Classes.Final? {
   return p as? Classes.Final
 }

Not sure how much that will affect the performance results until we get a runtime fix: rdar://90269352 (Always unwrap AnyHashable during dynamic casting)

[tbkka]

@atrick and I looked at the current runtime casting implementation and this optimization is not currently safe if the source is any kind of existential (including AnyObject). It's currently only safe for casting between concrete class types. I think AnyHashable may be the only real problem here; I'm going to fix that shortly.

[eeckstein]

I'm not sure about this. As far as I understand, this can only happen if the source is an AnyObject, but not another class existential.Also, isn't this only the case for Linux (non-objc interop runtime)?

[tbkka]

As far as I understand, this can only happen if the source is an AnyObject, but not another class existential.Also, isn't this only the case for Linux (non-objc interop runtime)?

I need to do a little more verification, but studying the casting code, it looks like this is a problem for all class existentials on all platforms.

[eeckstein]

@atrick I'm using the new doesCastPreserveOwnershipForTypes check now

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci test

[eeckstein]

@swift-ci test

[atrick]

LGTM

[compnerd]

This seems to have caused a pretty big regression on Foundation on Windows (CC: @millenomi) https://ci-external.swift.org/job/oss-swift-windows-toolchain-x86_64-vs2019/447/console

[eeckstein]

Thanks, I'll disable this optimization for Windows.