|
Message-ID: <CAPhv3non0txmmPMyUuUGVQONwZ1a_eupoeMN3AfiEusnUZ8WYQ@mail.gmail.com> Date: Wed, 22 Jan 2020 16:57:17 +0000 From: Luís Marques <luismarques@...risc.org> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: Re: [PATCH] Fix RISC-V a_cas inline asm operand sign extension On Wed, Jan 22, 2020 at 2:46 PM Rich Felker <dalias@...c.org> wrote: > Can you clarify why it's needed and why sign-extending is the right > thing to do, though? Does lr.w sign-extend the loaded value (vs > zero-extend or something else)? LR.W does indeed sign-extend the value read from memory, before storing it in the destination register (the ISA is quite consistent about sign-extending). The branch operates on the whole 64-bits, so the value to compare with must also be sign-extended. That's generally not a problem because the ABI mandates the sign-extension of the 32-bit int to XLEN (64 bits on rv64), and that's something that the compiler normally does automatically. The exception is the inline assembler, which in this case becomes a problem when the function is inlined. > Thanks for pinging this again. It's unfortunate that clang doesn't do > this right to begin with, but the patch is not terribly ugly and > probably okay. Yeah, this is a tricky issue. Unfortunately, it's a bit more complicated than just "clang doesn't do the right thing". A patch was proposed before to try to solve this issue [1], but this is an issue that already existed for other architectures, and where Clang and GCC were already inconsistent, both internally and compared to each other. The difference is that this issue generally only manifested itself with other C types (e.g. short). We (LLVM) could take a principled stance where we guaranteed that the values would be properly sign/zero-extended and truncated back (although my vague recollection is that that would be tricky, if at all possible), but that wouldn't guarantee compatibility with GCC, so you couldn't really rely on that behavior anyway. My understanding is that GCC's sign-extension of the value is an implementation quirk and not something guaranteed to happen, and will in fact not happen in other not too dissimilar cases. And the official stance of the GCC developers is that you can't rely on it, and a lot of other stuff related to inline assembly. Still, this is something that we want to improve in the future, because it's indeed tricky. But the fix might just be to warn of the issue and request that the value be explicitly casted. [1] https://reviews.llvm.org/D69212
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.