Question about negative `int<N>` literals and `top4` output

[eyg1331]

The P4 spec makes it clear that int<N> literals are expressed in the form <N>s<value>. In the examples given in the spec, negative literals use the two's complement representation for the <value> (eg. to represent -1 as an int<2>, we use 2s3) and an overflow warning is emitted.

I was curious how the compiler handles/represents this internally, so I tried constructing some IR nodes and outputting them (both manually using toString and via top4). In both cases, the emitted string had form -<N>s<abs-value> for negative values, which is valid P4 syntax but parses as the unary negation of a positive int<N> value rather than a single IR::Constant node.

This representation is warning-free for all values except the minimum value of the type (-2^(N-1)), which emits an overflow warning because its absolute value 2^(N-1) is out-of-range of int<N>. It seems to be semantically equivalent in all cases (though the minimum value case is a bit confusing because it relies on the fact that -(-2^(N-1)) = -2^(N-1) in N-bit two's complement).

This has me wondering how closely the top4 output is intended to match the input IR. Is it intended to be:
(a) recompileable (semantically equivalent, warnings acceptable) - current behavior
(b) recompileable without warnings
(c) recompileable with the same IR shape

In some sense, the answer above determines what the canonical representation for negative int<N> literals should be:

• if (a), the current -<N>s<abs-value> behavior makes sense as the top4 output
• if (b), the current behavior doesn't quite satisfy this due to the warning on the minimum value. Some workaround (such as a cast expression (int<N>)(value)) might be required.
• If (c), top4 should likely use the two's complement form seen in the spec's examples to match the IR shape more closely

I'm happy to open a separate bug/PR if the current behavior is considered unintentional. Mainly wanted to raise the question to understand the intended semantics first. Thanks!

[ChrisDodd]

This has me wondering how closely the top4 output is intended to match the input IR. Is it intended to be:
(a) recompileable (semantically equivalent, warnings acceptable) - current behavior
(b) recompileable without warnings
(c) recompileable with the same IR shape

Yes, all of the above. The problem is when there is no textual form that corresponds exactly to the IR. In that case, we create something that is semantically equivalent and "close" to it, so it will likely get transformed into the same IR after simple constant folding. Since the language has no syntax for negative constants, we need to use an operation on a positive constant -- a unary negate is the simplest, and clearest for most cases.

There was a proposal that the compiler recognize a negation on a signed constant literal that is out-of-range like this (so it corresponds to the most negative value) and NOT issue a warning for it. Priority for this is considered low, however.

[sanket-jadhav-cse]

Hi @ChrisDodd, I’d like to take up this low-priority improvement and work on refining the warning behavior around signed constant handling.

From my understanding, the issue arises when the compiler emits an overflow warning for expressions like -8s128, where 8s128 is technically out of range for int<8>, but the full expression correctly represents the minimum value (-128). I believe the compiler should detect this specific pattern—unary negation applied to an out-of-range signed literal—and treat it as a valid representation of the minimum value of int<N>, thereby avoiding a misleading overflow warning.

My plan is to carefully update the constant evaluation or type-checking logic to recognize this case without affecting existing semantics or the current top4 output format. I will also add targeted regression tests to ensure correctness and prevent future regressions.

Please let me know if this approach aligns with your expectations or if there are any specific considerations I should keep in mind before proceeding.