> On 18 Aug 2017, at 10:41 PM, Gabriel Paubert <paub...@iram.es> wrote: > > On Fri, Aug 18, 2017 at 10:29:04AM +1200, Michael Clark wrote: >> Sorry I had to send again as my Apple mailer is munging emails. I’ve >> disabled RTF. >> >> >> This one is quite interesting: >> >> - https://cx.rv8.io/g/WXWMTG >> >> It’s another target independent bug. x86 is using some LEA followed by SAR >> trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice. In any case >> RISC-V seems like a nice target to try to fix this codegen for, as its less >> risk than attempting a fix in x86 ;-) >> >> - https://github.com/riscv/riscv-gcc/issues/89 >> >> code: >> >> template <typename T, unsigned B> >> inline T signextend(const T x) >> { >> struct {T x:B;} s; >> return s.x = x; >> } >> >> int sx5(int x) { >> return signextend<signed int,5>(x); >> } >> >> riscv asm: >> >> sx5(int): >> slliw a0,a0,3 >> slliw a0,a0,24 >> sraiw a0,a0,24 >> sraiw a0,a0,3 >> ret >> >> hand coded riscv asm >> >> sx5(int): >> slliw a0,a0,27 >> sraiw a0,a0,27 >> ret >> >> x86 asm: >> >> sx5(int): >> lea eax, [0+rdi*8] >> sar al, 3 >> movsx eax, al >> ret >> >> hand coded x86 asm (no worse because the sar depends on the lea) >> >> sx5(int): >> shl edi, 27 >> sar edi, 27 >> movsx eax, dl > > Huh? dl is not a subreg of edi! > > s/edi/edx/ and it may work. > > dil can also be used, but only on 64 bit.
Sorry I meant dil on x86-64. I was sure that it was possible to extend into another register. I have not done much i386 asm so I am unaware of the constraints. Can the source and dest registers for movsx not differ on i386? I thought they could. In any case, the plot thickens… I believe we have bugs on both RISC-V and Aarch64. I found that it at least appears like it is transitioning to a char or short as the break is at 24 and 16 depending on the width, and values over 16 work as one would expect. Here is an updated test program: https://cx.rv8.io/g/M9ewNf template <typename T, unsigned B> inline T signextend(const T x) { struct {T x:B;} s; return s.x = x; } int sx3(int x) { return signextend<signed int,3>(x); } int sx5(int x) { return signextend<signed int,5>(x); } int sx11(int x) { return signextend<signed int,11>(x); } int sx14(int x) { return signextend<signed int,14>(x); } int sx19(int x) { return signextend<signed int,19>(x); } I filed a bug on riscv-gcc but I think it is target independent code given there appears to be an issue on Aarch64. AFAICT, Aarch64 should generate a single sbfx for all of the test functions. - https://github.com/riscv/riscv-gcc/issues/89 Should I file a bug on GCC bugzilla given it looks to be target independent? On RISC-V, the codegen is much more obviously wrong, but essentially the same thing is happening on Aarch64 but there is only one additional instruction instead of two. sx3(int): slliw a0,a0,5 slliw a0,a0,24 sraiw a0,a0,24 sraiw a0,a0,5 ret sx5(int): slliw a0,a0,3 slliw a0,a0,24 sraiw a0,a0,24 sraiw a0,a0,3 ret sx11(int): slliw a0,a0,5 slliw a0,a0,16 sraiw a0,a0,16 sraiw a0,a0,5 ret sx14(int): slliw a0,a0,2 slliw a0,a0,16 sraiw a0,a0,16 sraiw a0,a0,2 ret sx19(int): slliw a0,a0,13 sraiw a0,a0,13 ret
