I think I see the issue. When projecting, we have special handling for _PUSH_FRAME that assumes the cache layout is the same as _PyCallCache, and it reads the func_version to continue projecting out of that. I think that currently, it's reading garbage and failing to continue projecting, but maybe it occasionally gets something that looks like a valid function version present in the cache... yikes!

So I think for this to work, we need to add a cache entry to every BINARY_SUBSCR, where BINARY_SUBSCR_GETITEM stores the __getitem__'s func_version. The current specialization is sort of nice in that it works for any heap type with a cached __getitem__, but I don't think making it specific to one cached function would hurt too much (note that this will still work for polymorphic sites with the same inherited __getitem__ function).

@brandtbucher Thanks for the analysis

It looks like we bail out of projection in _PUSH_FRAME if the opcode is FOR_ITER_GEN. We can just do the same for BINARY_SUBSCR_GETITEM for now and consider a more sophisticated approach later.

Well, that was a bug. But not the bug that's causing this to fail.

This failure seems interesting:

test_combine_stack_space_checks_large_framesize (test.test_capi.test_opt.TestUopsOptimization.test_combine_stack_space_checks_large_framesize) ... python: Python/optimizer.c:952: translate_bytecode_to_trace: Assertion `trace_length < max_length' failed.

I just kicked off JIT benchmarks and stats for you.

2% fewer tier one instructions. Overall perf impact is in the noise, but two SymPy benchmarks got 15% faster.