bpo-46841: Use inline caching for attribute accesses#31640
Conversation
|
(We're also going to want to hit this with the buildbots once it's working.) |
Sorry, something went wrong.
markshannon
left a comment
There was a problem hiding this comment.
I like the change to use arrays in the structs. It's much clearer that my _m1 field.
But, be careful of casting one struct to another, and be aware that the C compiler treats arrays as simple pointers.
Sorry, something went wrong.
|
When you're done making the requested changes, leave the comment: |
Sorry, something went wrong.
Okay, that was officially the wildest bug I've ever dealt with. The problematic bytecode sequence (buried deep in Quickened: After specializating the first Finally, after specializing the second Did you catch that? The cached index was turned into a The code that did that is here. Basically, the low byte of the cached index just happened to be What it really did, though, was change the module attribute cached index from Phew. |
Sorry, something went wrong.
|
This whole incident highlights one limitation with the new inline caching approach: it's no longer safe to peek backwards at previous instructions, since you might actually be looking into a cache entry instead. I don't see how we can keep I'll also go over the existing specialization code and see if we're doing this anywhere else. |
Sorry, something went wrong.
|
It also highlights the need for a |
Sorry, something went wrong.
|
Looping in @sweeneyde, since I might need to get rid of |
Sorry, something went wrong.
I didn't see the macro benchmark needle move too much when it was added, so if it's architecturally necessary to, I have no problem with it being scrapped for now. |
Sorry, something went wrong.
|
🤖 New build scheduled with the buildbot fleet by @brandtbucher for commit 452c78c 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
Sorry, something went wrong.
|
Buildbot failures look unrelated. |
Sorry, something went wrong.
CC @markshannon. These three share a lot of code, so it makes sense to convert them together.
Marking asDO-NOT-MERGEsinceLOAD_ATTR_MODULEis somehow causing assertion failures and unclosed resources intest_asyncio:Details
Any ideas on why that might be are definitely appreciated... I've been staring at this for a while and am completely at a loss.The rest of the PR is ready for review, though.https://bugs.python.org/issue46841