On 2014-04-24 13:01, Richard Henderson wrote: > > Our 32-bit build for sparc has been requiring a 64-bit capable chip > for about 2 years now, by way of requiring move-conditional and LE > memory instructions. But we've mostly been generating 32-bit code > otherwise. > > This patch set changes things so that we make full use of the cpu. > > The sparcv8plus code model requires that 64-bit data be kept only > in the %g and %o registers. These are saved by the kernel in full > 64-bit slots somewhere. Whereas the %i and %l registers are saved > via the register window mechanism, and as part of the 32-bit ABI > we've only allocated 32-bits of stack for storing these. Since the > register window can roll at any time, due to signals and interrupts, > we must consider the high bits of %i and %l to be garbage. > > This implies that we must treat 32-bit and 64-bit quantities differently. > For the most part, TCG is good with that. The one case where that falls > down, however, is when we frob data between widths. Thus the addition > of the trunc_shr_i32 opcode. > > This new opcode, or something like it, would have been required if > we ever got around to supporting MIPS64 code generation, where 32-bit > quantities must remain sign-extended in the 64-bit register at all times. > > In the case of sparcv8plus, we can get what we need out of the opcode > merely by setting its register constraints properly.
I am currently trying to review how we handle 32 to 64 and 64 to 32-bit conversions in QEMU and I have a question about the (now not so) new trunc_shr_i32 opcode. Sorry for answering such an old email. While I understand why we need the new trunc_shr_i32 opcode for MIPS64 (the 32-bit values must be kept sign-extended), I currently fail to see why it is needed for SPARC. I understand only some registers can be used to store a 64-bit value, but this is not the case for 32-bit values. I therefore don't see why we would need any specific constraint for the 64 -> 32 bit conversion (I understand for ext32u and ext32s). Does it mean that SPARC needs to keep 32-bit values zero-extended? It doesn't make sense either given the high bits of some of these registers can become garbage at any moment. Can you please give some more details about this so that I can add SPARC target support to the "tcg: improve size changing ops" series? Thanks. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
