Decide what a shift count at or beyond the operand width means for classical expressions

[ciaranra]

The classical expression evaluators do two different things when a shift count reaches or exceeds the operand's width, and the inconsistency is about to become visible.

In the PHIR interpreter, an unsigned shift in either direction returns zero once the count reaches the width, because it goes through the fixed-width bit shift. A signed right shift instead masks the count to 64 bits, because it goes through Rust's wrapping_shr. So a signed value shifted right by 64 comes back unchanged rather than filled with its sign bit. The Python interpreter computes the same thing, by an explicit modulo, so the behaviour is pinned bit-for-bit by the parity test and cannot be changed on the Rust side alone.

The QASM engine does neither: it clamps the count to the operand's width, so a shift by 64 or more yields zero in both directions.

#869 moves both onto one shared evaluator, so one of these has to give. The options, as far as I can see them:

• Saturate everywhere. A count at or beyond the width yields zero for a logical shift and all sign bits for an arithmetic right shift. This is the rule most people expect, and it makes the two directions consistent. It changes PHIR behaviour for signed right shifts by 64 or more, so the Python interpreter changes with it and the parity fixtures move.
• Keep the count masked to the width everywhere. Consistent in a different way, and matches what C compilers actually do on most hardware, but it is the behaviour people are surprised by, and it would change QASM.
• Keep each evaluator as it is, which means the shared evaluator carries a flag, and the flag exists forever.

My recommendation is to saturate, and to change the Python interpreter in the same change so the two stay bit-for-bit. Shifting a value further than its own width is not a meaningful request, and of the two possible answers, zero and sign-fill is the one that does not depend on knowing the evaluation width.

This does not block #869. Slice B preserves the current behaviour exactly rather than inventing a rule, so the decision can be made on its own schedule, and slice C classifies whatever it inherits.

[ciaranra]

A scout checked the specifications and the comparable systems, and the result narrows this question and corrects my earlier recommendation.

No specification decides it. The PHIR specification lists a left shift and a right shift and says nothing about a count at or beyond the operand width, a negative count, or the signedness of an arithmetic right shift result. OpenQASM 3 does not specify the count behaviour either, though it does require the count to be unsigned. OpenQASM 2 has no classical arithmetic at all, so the shift operators in the PECOS QASM engine are an extension we own outright.

The comparable systems are split rather than pointing one way, which is not what I assumed when I recommended saturating. C and C++ leave it undefined. Rust's operators overflow, its wrapping forms reduce the count modulo the width, and its checked forms return nothing. RISC-V uses only the low six bits of the count register. SystemVerilog fills, with zeros for a logical shift and the sign for an arithmetic one, and treats the count as unsigned. Python has no fixed width. So masking, which is what we do for the arithmetic right shift today, matches Rust's wrapping form and the hardware; saturating matches SystemVerilog.

What the scout did settle is how small the actual divergence is. Logical shifts already saturate everywhere: the PHIR unsigned path, the QASM engine, and a Guppy test that expects zero for a past-width shift. The only rule that reduces the count modulo the width is the arithmetic right shift. The sixteen-bit truncation is separate and applies to every shift, and it is an artifact of a cast to a sixteen-bit count rather than a decision anyone made.

So the question is really two smaller ones.

First, should an arithmetic right shift by a count at or beyond the width give all sign bits rather than reducing the count? I still recommend yes, now for a better reason than before: every other shift in the project already saturates, so this is the one case that is inconsistent with its neighbours, and no specification requires the other behaviour.

Second, should the sixteen-bit truncation go? I recommend yes. It makes a shift by 65536 a shift by nothing, which nobody chose and nothing documents outside the code.

The blast radius is small and now enumerated. No separate fixture files are affected. Inside the shared evaluator's tests, the cases that change are the wide-count decoding test, which currently pins that the accessor reports zero rather than the low word when a high word is set, and the boundary counts around 65536. The QASM engine has its own saturation tests that already match the proposed rule. Both interpreters would change together, as before.