On Tue, Jan 25, 2011 at 08:13:53AM -0800, Richard Henderson wrote: > On 01/25/2011 04:27 AM, Edgar E. Iglesias wrote: > > I've tested this patch a bit and got mixed results. I tested with patched > > CRIS and MicroBlaze translators. The patch works OK (it doesn't break > > anything) for the usecases I had but I saw a bit of a slowdown with > > MicroBlaze (compare to not using deposit at all). > > > > I suspect that the fast 8 and 16 bit x86 deposits are giving me a slight > > speedup with CRIS. But MicroBlaze uses one bit fields into bit 2 and > > 31. Those seem to be slower with deposit than with other tcg sequences. > > > > I would have guessed that at worst, this patch would be equally fast > > as any TCG sequence. Am I missing something? > > With or without the i386 tcg-target.c changes? > > If without, then I'm stumped, since it looks like identical tcg ops > being emitted.
It's with the tcg-target patch. > It with, then perhaps SHLD is slower than I thought. I see that GCC > lists this insn as "vector decoded" for AMD cores, as opposed to > "direct decoded". If this insn is indeed microcoded on some hosts > then maybe the i386 tcg-target patch isn't such a great idea. OK, I see. Maybe we should try to emit an insn sequence more similar to what tcg was emitting (for the non 8 & 16-bit deposits)? That ought too at least give similar results as before for those and give us a speedup for the byte and word moves. > That said, there are still other tcg targets which support this > operation directly. I would be shocked if you measured a slowdown > with these changes on a ppc host, for instance. Yep, agreed. Cheers
