gh-104635: Add NO_EXCEPTION flag to opcode metadata

[corona10]

This PR is motivated from comments from @iritkatriel and @carljm.

There are several code patterns that can cause multiple stores to the same locals index in near succession,
...
Also need to make sure there isn't something between them that could raise an exception. We don't currently have this, > we probably need to add this in the opcode_metadata.

But I'm not sure if this is the concept Irit originally intended, so I write the PR as the PoC with heuristic codes that will not raise exceptions.
If there is something I missed, please let me know.

We can use this metadata for aggressive optimization between two opcodes that will not raise exceptions.

• Issue: dead store elimination in the compiler #104635

[iritkatriel]

What is the heuristic to determine whether an opcode raises?

[corona10]

What is the heuristic to determine whether an opcode raises?

I thought that we should use a blocklist approach or allowlist approach for classifying opcodes.
In the current implementation, I used a blocklist approach.

1. if the opcode calls any APIs that begin with _Py or Py (including Py_Incref), it has the possibility of causing an exception.
2. Another case is ERROR_IF, it has the possibility of an error exception before the macro is called.

The reason for skipping JUMPXXX opcode as an exceptional case is that the current implementation does not pass the assertion of the analyzer. I should analyze why this happening but before that, I wanted to sync the idea of this metadata before digging into it.

[carljm]

It's not clear to me that "exception-raising" status of an opcode changes enough that we need to automatically determine this metadata via heuristic on the opcode implementation, rather than just manually maintain it.

I'm not necessarily opposed, if we can find a sufficiently conservative heuristic that does not fail in the unsafe direction. But I'm not sure I see any such possible heuristic, given my inline comment.

[carljm]

Negative flags tend to lead to confusing double-negative code constructs. So I would prefer for the flag to be CAN_RAISE_FLAG than NO_EXCEPTION_FLAG, and similar throughout the PR.

[carljm]

There are static helper functions in ceval.c that are used by opcodes and not Py prefixed, and some of these can raise. E.g. match_class. We can special case the existing ones, but someone could add a new one at any time. So I don't think this heuristic is safe, and I'm not sure I see any possible heuristic that would be safe in the face of possible future changes.

[carljm]

I guess the match_class case should be covered by ERROR_IF used afterward to check if _PyErr_Occurred. But what if someone calls a non Py prefixed helper function and then uses a manual goto error; rather than ERROR_IF? There are some opcodes that use goto error; directly...

Maybe checking for both ERROR_IF and goto error would be adequate, and we wouldn't even need to check for use of Py prefixed API? For an opcode implementation to handle an error correctly, it seems it needs to goto error or ERROR_IF. Unless someone introduces another new macro that includes goto error, that would break the heuristic.

Existing macros that implicitly goto error include CHECK_EVAL_BREAKER, DECREF_INPUTS_AND_REUSE_FLOAT, and INSTRUMENTED_JUMP.