Optimize new uops added for trace recording

[markshannon]

#144179 added recording of values to the trace recorder.
It also fixed some correctness issues around calls and returns (and sends and yields), but the optimizer hasn't caught up, resulting in a performance drop.

To fix that we need to:

• optimize away the new guards, using function and code watchers.
• convert recorded functions and guarded code/function values into known constants in the optimizer
• Likewise for recorded code objects

Linked PRs

• GH-144651: Optimize the new uops added when recording values during tracing. #144948
• gh-146018: Disable over-aggressive optimization for _GUARD_CODE_VERSION #145923

[Kaushalt2004]

I would Like to make a review for this

[Fidget-Spinner]

@Kaushalt2004 sorry but could you please stop spamming issues claiming you would like to make a review? If you want to make a review, you can always just leave a review on the PR. There is no need to say you want to review on the issue.

[Fidget-Spinner]

Now that I think about it a bit more, why do we need _GUARD_CODE again? Unless I'm mistaken, the only way we can change the code version is if the code object itself changes. Aren't code versions basically immutable once set?

So we should only need a function watcher, not a code watcher? After all, bytecode instrumentation triggers executor invalidation too.

[markshannon]

We need _GUARD_CODE to check that execution is following the same path as the one we recorded.

[Fidget-Spinner]

We need _GUARD_CODE to check that execution is following the same path as the one we recorded.

Isn't that the point of _GUARD_IP?

[markshannon]

The _GUARD_IP uops check the instruction pointer is the same, not the code object.
The code object could either have been deleted and replaced by another at the same location, or (more likely) been instrumented.
There may be some redundancy, but that's fine as the optimizer will removed it (once I've implemented that).

[Fidget-Spinner]

This introduced a bug #144414 (comment)