On Fri, Apr 04, 2003 at 12:02:00PM -0500, Chuck Ebbert wrote:
> Juan Quintela wrote:
>
>
> >Reason is that:
> >
> >if (expr)
> > var = true;
> >else
> > var = false;
> >
> >is always a bad construct.
> >
> >var = expr;
> >
> >is a better construct to express that meaning.
>
>
> Yes, but:
>
> if (expr1 && expr2)
> var = true;
> else
> var = false;
>
> is usually better turned into something that avoids jumps
> when it's safe to evaluate both parts unconditionally:
>
> var = (expr1 != 0) & (expr2 != 0);
>
> or (if you can stand it):
>
> var = !!expr1 & !!expr2;
Such ugly transformations are a job for compiler writers and may
occassionally be acceptable in some critical paths. The IO path, which
is literally dozens of function calls deep from read()/write() to
driver methods, does not qualify.
FYI, GCC as of 3.2.3 doesn't yet reduce the if(...) form to branchless code
but the & and && versions come out the same with -O2.
-- Matt Mackall : http://www.selenic.com : of or relating to the moon - 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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:21 EST