![]() | |||||||||||
Messages in this thread |
On Sat, 8 Jul 2006, Ralf Baechle wrote: > > I tried the same on MIPS, for lazyness sake at first only in atomic.h. With > gcc 3.3 the code size is exactly the same with both "=m" and "+m", so I > didn't look into details of the generated code. With gcc 4.1 "+m" results > in a size increase of about 1K for the ip27_defconfig kernel. For example: > > <unlock_kernel>: > df830000 ld v1,0(gp) > 8c620028 lw v0,40(v1) > 04400014 bltz v0,a80000000029944c <unlock_kernel+0x5c> > 00000000 nop > 2442ffff subiu v0,v0,1 > ac620028 sw v0,40(v1) # current->lock_depth > 8c630028 lw v1,40(v1) # current->lock_depth > 0461000b bgez v1,a80000000029943c <unlock_kernel+0x4c> > > The poinless load isn't generated with "=m". The interesting thing is > that in all the instances of bloat I looked at it was actually happening > not as part of the asm statement itself, so maybe gcc's reload is getting > a little confused. Indeed, that looks like gcc confusion, because that pointless load is literally just re-loading the "task->lock_depth" that is all part of perfecly normal C code _before_ the inline assembly even is reached. Of course, if a "+m" causes gcc confusion, that's bad in itself, and indicates that "=m" + "m" may actually be preferable due to some internal gcc buglet. I do _not_ see the same extra load on ppc64 or indeed x86 (gcc-4.1.1 in both cases), so there seems to be something MIPS-specific here. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||
| Last update: 2006-07-09 05:13 [from the cache] ©2003-2008 | |||||||||||