On 2015-07-17 12:23, Aurelien Jarno wrote: > On 2015-07-16 22:29, Richard Henderson wrote: > > On 07/15/2015 09:54 PM, Aurelien Jarno wrote: > > >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. > > > > As far as I recall, it improves code for extracting high parts of 64-bit > > quantities. Without this, we wind up with a 64-bit shift, requiring a > > 64-bit temp register, followed by the "real" truncate which can copy the > > data to a 32-bit destination register. > > Ok, I understand the use case now. So it's not for correctness, but > rather to generate more optimized code.
OTOH, it means that we always have to go through a 32-bit register first when truncating a 64-bit value. I mean we gain in the following case: shr_i64 t64, t64, i trunc_i64_i32 t32, t64 ... But we lose in the following case: trunc_i64_i32 t32, t64 neg t32, t32 ... Overall I guess the advantages far outweigh the disadvantages. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
