Messages in this thread | | | Date | Tue, 29 Feb 2000 16:01:00 -0800 | From | "Jeffrey B. Siegal" <> | Subject | Re: Kernel bugs found using inspect tool |
| |
Ben Kosse wrote: > "Jeffrey B. Siegal" wrote: > > > > Ben Kosse wrote: > > > > > > > nathan.zook@amd.com wrote: > > > > > > if((a == b) | (c == d) | (e < f)) > > > > If c, d, e and f are simple variables, then the compiler should be able to > > > > tell that it makes no difference whatsoever whether | or || is used, and > > > > should generate the same (fastest) code for both. > > > Not necessarily true. || has the side effect of allowing you to jump out > > > after the first comparison. | *REQUIRES* you do all comparisons. > > Reread carefully. If "c, d, e, and f are simple variables" then the > > expression in question can not have side effects, and it makes no difference > > whether all the comparisons are performed or not (nor what in order they are > > performed). > And that's my point. The *very use* of || *creates* a side effect that the > compiler is free to use, and in fact used to be commonplace. At one point in > time, people would write the code with the most frequent occurance first and > the compiler would generate a list of cmp/jmp pairs. & vs && also creates > side-effects. > > 10 | 11 | 00 == 11 > 10 || 11 || 00 == (expression that evaluates to true)
Again, *please* look back at the example in question. Each operand of the "or" operator is the result of a C comparison operator that returns either 0 or 1. In this case it makes *no difference whatsoever* whether | or || is used. As I said, the compiler should be able to recognize that the two are equivalent and generate the fastest code (either using conditional short-circuiting or not, as the case may be) regardless of which "or" operator is used.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |