gh-148510: restore func_version check in _LOAD_ATTR_PROPERTY_FRAME

[NekoAsakura]

Do not merge.
Prerequisite: #148524
Mean +- std: [main] 12.8 ms +- 0.2 ms -> [branch] 12.3 ms +- 0.1 ms

• Issue: _LOAD_ATTR_PROPERTY_FRAME has too weak checks that are also slow #148510

[Fidget-Spinner]

Just one thing that should be addressed. Thanks!

[Fidget-Spinner]

Note: this does not need an FT_ATOMIC_ load (check the rest of bytecodes.c). On FT, I suspect it's because function verison resets are stop-the-world (see Objects/funcobject.c)

[NekoAsakura]

Would you like me to document this in a comment?

[Fidget-Spinner]

No it's fine. The rest of bytecodes.c works like that and has no comments too.

[Fidget-Spinner]

This needs a stronger invariant. There might be a case where fget is deallocated or deleted, and we are thus accessing a NULL pointer!

The reason why this is safe currently in the bytecodes interpreter but not here is that we have _GUARD_TYPE_VERSION in the bytecodes interpreter that guarantees that our cached function is alive.
While here, the _GUARD_TYPE_VERSION only sets the type version, and doesn't stop optimization if we detect something wrong.

To make this safe, you need to get the probable type in _GUARD_TYPE_VERSION, and also set things to contradiction+done if they don't already match the type_version in there. Since we record LOAD_ATTR_PROPERTY's type, this will then be safe to access if that passes.

[NekoAsakura]

Seems like probable_type gets dereferenced without a NULL check here.

cpython/Python/optimizer_bytecodes.c

Lines 143 to 145 in 21da9d7

	if (probable_type->tp_version_tag == type_version && sym_set_type_version(owner, type_version)) {
	// Promote the probable type version to a known one.
	if ((probable_type->tp_flags & Py_TPFLAGS_IMMUTABLETYPE) == 0) {