On Saturday 06 August 2005 18:57, Jeff Garzik wrote: > On Sat, Aug 06, 2005 at 09:50:13AM +0100, Matthew Wilcox wrote: > > On Fri, Aug 05, 2005 at 11:34:55PM -0400, Jeff Garzik wrote: > > > FWIW, compilers generate AWFUL code for bitfields. Bitfields are > > > really tough to do optimally, whereas bit flags ["unsigned int flags & > > > bitmask"] are the familiar ints and longs that the compiler is well > > > tuned to optimize. > > > > I'm sure the GCC developers would appreciate a good bug report with a > > test-case that generates worse code. If you don't want to mess with their > > bug tracking system, just send me a test case and I'll add it for you. > > Its an order-of-complexity issue. No matter how hard you try, > bitfields will -always- be tougher to optimize, than machine ints. > > Bitfields are weirdly-sized, weirdly-aligned integers. A simple look at > the generated asm from gcc on ARM or MIPS demonstrates the explosion of > code that can sometimes occur, versus a simple 'and' test of a machine > int and a mask. x86 is a tiny bit better, but still more expensive to > do bitfields than machine ints.
But we are talking about one-bit field here: + unsigned int no_msi:1; /* device may not use msi */ If _this_ isn't optimized nicely into ANDs, ORs, etc, then bug report is in order and gcc should be fixed. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/