lkml.org 
[lkml]   [2000]   [Feb]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.037 / U:1.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site