[FFmpeg-devel] & vs. &&

[Måns Rullgård]

Kostya <kostya.shishkov at gmail.com> writes:

> On Mon, Oct 12, 2009 at 03:11:26PM +0100, M?ns Rullg?rd wrote:
>> Kostya <kostya.shishkov at gmail.com> writes:
>> 
>> > On Mon, Oct 12, 2009 at 02:21:06PM +0200, Benoit Fouet wrote:
>> >> Hi,
>> >> 
>> > [...]
>> >> second one:
>> >> libavcodec/vc1dec.c:2318: warning: suggest parentheses around operand of
>> >> ?!? or change ?&? to ?&&? or ?!? to ?~?
>> >> =========== ><8 ===========
>> >> if(!coded_inter) coded_inter = !is_intra[i] & is_coded[i];
>> >> =========== 8>< ===========
>> >> 
>> >> although this is the same functionnaly as '!is_intra[i] && is_coded[i]',
>> >> I find the latter more close to what we really want to test.
>> >> 
>> >> I'd suspect the second case should be fixed as suggested (i.e. '&' =>
>> >> '&&'), but would like to hear knowledgeable people for the first one.
>> >
>> > Yep, it should be the same for the second case, so change it if you like.
>> 
>> Beware, the && version might be slower.
>
> Something tells me that it may be a sign of GCC meddling with operator
> priorities (there was similar story with shifts, wasn't it?).

The thing here is that the RHS of the && operator must not be
evaluated if the LHS is false.  This means the compiler will have to
use some kind of conditional code, probably a branch, to avoid reading
is_coded[i] if is_intra[i] is non-zero.  A single read followed by a
bitwise and is almost certainly faster than a conditional branch,
especially if it is hard to predict.

-- 
M?ns Rullg?rd
mans at mansr.com