Messages in this thread | | | Date | Thu, 16 Dec 2010 11:17:25 +0100 | Subject | Re: x86: A fast way to check capabilities of the current cpu | From | Miguel Ojeda <> |
| |
On Thu, Dec 16, 2010 at 7:25 AM, Miles Bader <miles@gnu.org> wrote: > "H. Peter Anvin" <hpa@zytor.com> writes: >>> In this case it this_cpu_*_test_bit() return an int, but they act as a >>> bool and are used in if()s; where is the catch? >> >> If they aren't, and are stored in a variable for whatever reason, then >> the || form will generate additional instructions to booleanize the >> value for no good reason. > > It doesn't actually have to "booleanize" the value if it's used in a > boolean context though (and, AFAICT, usually won't). > > My vague impression is that when used in a boolean context, gcc will > often generate the same or "equivalent" code for both variants -- but > sometimes a||b seems to generate better code; e.g.: > > static inline int test1a (int a, int b) { return a ? 1 : b; } > int test1b (int a, int b) { if (test1a (a,b)) return a+b; else return 37; } > > static inline int test2a (int a, int b) { return a || b; } > int test2b (int a, int b) { if (test2a (a,b)) return a+b; else return 37; } >
I think hpa was talking about some code where gcc can not optimize out the assignment (e.g. volatile, complex code, using the int outside conditional expressions, etc.).
>=> > > test1b: > testl %edi, %edi > jne .L2 > movl $37, %eax > testl %esi, %esi > jne .L2 > rep > ret > .L2: > leal (%rsi,%rdi), %eax > ret > > test2b: > leal (%rsi,%rdi), %edx > movl $37, %eax > orl %edi, %esi > cmovne %edx, %eax > ret > > .ident "GCC: (Debian 4.5.1-8) 4.5.1" > > > -Miles > > -- > Is it true that nothing can be known? If so how do we know this? -Woody Allen > -- 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/
| |