-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
riscv codegen oddity: emits (hopefully no-op) signext for a u32 param. #98151
Comments
(my current guess is that this supposedly incorrect |
(this was spawned off my attempt to craft a more general test case for #97800) |
In RV64 all 32-bit operations will be sign-extend to 64-bit, unlike other platforms. (The intention being that this will 64-bit comparison also work directly on 32-bit values, so no need for additional branch instructions) |
Unsigned 8-bit and 16-bit values are essentially zero-extended into 32-bit values (regardless RV32 or RV64), and then in RV64 the zero-extended value is then sign-extended into 64-bit, which effectively make them being zero-extended directly into 64-bit. EDIT: Some background, in RV64 there are native instructions operating on 32-bit values, but neither RV32/64 have native instructions dealing with 8 or 16-bit values. |
So the current behaviour is correct and expected. |
As per the last comment, removing priority from this issue (Zulip discussion). @rustbot label -I-prioritize |
In spite of the popular rumor that LLVM's instruction set is "architecture-neutral", there are quite a few architecture-specific variations in the "LLVM ISA". But some things do have an architecture-neutral implication, even when they have architecture-specific meaning. In particular, the Thank you for reporting! It seems this is notabug, so I am closing this. |
I tried this code:
Note the compile flags; thus I invoked the compiler like so:
I expected to see this happen:
Semi-uniform handling of unsigned and signed extension of the arguments/return values. Namely, I would expect
uN
types to be (at most) zero-extended, andiN
types to be (at most) signed-extended.Instead, this happened: The u32 handling emits a signext attribute, like so:
I think this ends up acting as having no effect, but its weird nonetheless to have it there.
The text was updated successfully, but these errors were encountered: