bpo-44337: Improve LOAD_ATTR specialization

[markshannon]

We were being overly conservative by not specializing for instance attributes when the class also has an attribute.
It is OK to perform that specialization if the class attribute is not an overriding descriptor (and has an immutable class, so it will remain so).
This requires more detailed analysis of the class attribute, so this is factored out in a new function, which we can also use when we specialize STORE_ATTR.

This PR also specializes obj.__class__ using LOAD_ATTR_SLOT.

https://bugs.python.org/issue44337

[markshannon]

Performance results: https://gist.github.com/markshannon/f938b10691f081b3a6cdad54521890fb

[ericsnowcurrently]

mostly LGTM

I did not notice any logical problems or bugs. I've left a number of clarifying questions and a few minor suggestions. I do not consider any of them to be blockers, especially since this PR is an improvement regardless of my comments. However, in a couple of the cases it would be worth having a bit of discussion before merging.

Specifically:

• should we also identify descriptors for type objects (currently ignored since they have type.__getattribute__ instead of object.__getattribute__)?
• move analyze_descriptor() to typeobject.c (and make it part of the internal API)?

[ericsnowcurrently]

Performance results: https://gist.github.com/markshannon/f938b10691f081b3a6cdad54521890fb

Any thoughts on why some of those benchmarks are showing performance regressions?

[markshannon]

Performance results: https://gist.github.com/markshannon/f938b10691f081b3a6cdad54521890fb

Any thoughts on why some of those benchmarks are showing performance regressions?

Not really, nor why unpack_sequence is 18% faster

[ericsnowcurrently]

LGTM

Thanks for the feedback on my questions/comments. The changes make sense and analyze_descriptor() is a definite improvement.

[bluss]

I would worry this (__CLASS__) would be a used or reserved name in some C implementation. Identifiers with __ are generally reserved by the C std.