Took a quick look at this. It's edge case analysis again, similar to bug 1719884, but more straightforward. In NeedNegativeZeroCheck, if the only uses of a
Mul are either resume points or allow-listed, then we decide that a negative zero check isn't needed. However, this means that when we hit the end of the loop and bail out (because we've never executed the print statements before), the value we recover is +0.
We've already talked about getting rid of EdgeCaseAnalysis entirely, since it's mostly (but not entirely) redundant with range analysis. Last time we decided to do the spot fix, and wait to see whether additional issues appeared. This is an additional issue, which might mean it's time to pull the trigger on removing EdgeCaseAnalysis. The downside is that we lose a few small optimizations. One alternative would be to return true in
NeedNegativeZeroCheck if any consumer is a resume point. A very quick assert-based experiment shows that we would still remove a non-zero number of negative zero checks in Octane. I'm not sure whether that justifies keeping the optimization around, though.
This isn't a security problem: no delicate optimizations in Warp can depend on the sign of this zero, because if any consumers cared about the sign, we wouldn't have removed the check.
(Aside: note that we can safely lower this to a
MulI so long as we don't also remove the negative zero check here.)