I can easily see the optimizer turning"aaa"[:0] into"".
empty doesn't need to be a constant, we just need it to be mostly "", for profiling.
Use something likeempty = "a"[:(n % 1000) == 0]

Since we check the actual path taken as part of the test, we need the value toalways be"", not justmostly"". So maybe:

false=i==TIER2_THRESHOLDempty="X"[:false]

The optimizer can't provefalse isFalse, so it's good enough for our purposes.

This is strictly incorrect. We don't know thatvalue is "" until after the_GUARD_IS_FALSE_POP.
The reason that matters is that when we start attaching type information to side exits, as we probably will in 3.15, then this could lead us to infer thatvalue is "" on both branches. Which would be wrong.

There are two possible fixes for this.

• CombineTO_BOOL_STR and_GUARD_IS_FALSE_POP/_GUARD_IS_TRUE_POP into a single (super)instruction, then optimize that.
• Annotate the bool value resulting from theTO_BOOL with its input, then in_GUARD_IS_FALSE_POP convert the input value toTO_BOOL.

I prefer the second option, although it may be more work, as it is more flexible and can be extended more easily.

Yeah,@Fidget-Spinner and I suggested something like the latter on the issue (new symbols likeJitBoolOf(JitOptSymbol *source, bool inverted) andJitEqualTo(JitOptSymbol *lhs, JitOptSymbol *rhs, bool inverted)). That's probably the direction we're headed in longer term.

However, I don't think we should let perfect be the enemy of good here. We have nice, working optimizations in these PRs; just because wemight sink info onto side exits in the future probably shouldn't prevent us from making changes like this now for 3.14, which are perfectly correct for the current optimizer (which doesn't sink anything).

I'm inclined to land these changes and other similar ones for==/!= now, and make the symbolic representation of derived boolean values more complex later as an improvement (it will also be able to handle more uncommon cases likex = y == 42; if x: ...). I'm really worried that if we try to "future-proof" optimizations based on what wecould do six months from now, it will prevent actual improvements in the near term.

But I'll defer to you here. If havingvalue be narrowed one uop too early in the instruction stream is enough to block this PR, I can work with these new contributors on the more complex solution. But as-is, this has no bugs and works as intended. We don't sink value info onto side exits, so it's correct.