[PATCH libX11 1/2] xcb_io: Fix Xlib 32-bit request number wrapping

[Jonas Petersen]

Am 18.11.2013 00:33, schrieb Mouse:
>>>>      *wide = new + ((unsigned long) (new < *wide) << 16 << 16);
>>>> The comment says "Treating the comparison as a 1 and shifting it
>>>> avoids a conditional branch".
>>> Only on architectures with conditional moves - and, on those, the
>>> version using ? : is likely to compile down to a conditional move
>>> anyway.  I think that comment should be fixed.
>> What do you mean exactly?
> Computing the numeric value of (a < b) - as opposed to using it in a
> control-flow construct - is normally implemented much the same way that
> ((a < b) ? 1 : 0) is.  By definition of the < operator, they are
> semantically identical anyway.
>
>> I thought the comment was saying that using "(x < y) << z" is
>> avoiding a conditinal branch introduced by using an "if" or "? :" in
>> some way to get the calculation done.
> That's what I think the comment is saying, yes.  I also think it's
> false - or, at least, it's false more often than it's true, and in a
> way that's unpredictable from the point of view of anyone who actually
> needs the comment.
>
> On architectures without conditional moves, it's difficult[%] to
> compute the numerical value of (x < y) without a conditional branch.
> And on architectures with conditional moves, ((x < y) ? 1 : 0) will
> likely use a conditional move rather than a branch anyway.
>
>> Isn't the comment true then?
> It depends on the compiler, the target CPU architecture, and possibly
> other things (like the optimization tradeoffs the compiler has been
> told to use).  But if the optimizer is even half-decent, (x < y) << z
> and ((x < y) ? 1 : 0) << z will compile to exactly the same
> instructions.
>
> I think it is likely enough that it's false that leaving the comment
> there with that wording is a bad idea; I also see it as a instance of
> pushing a very very machine-dependent tradeoff up to the C level,
> something that is better left to the optimizer, or at the very least
> buried in a machine-dependent preprocessor macro.
>
> [%] Not impossible; it can be done with arithemtic and logical
>      operations.  I'd render the core of the idea in 32-bit C as
>      ((x-y)>>31)&1 - that's got issues with numbers large enough that
>      their high few bits aren't all the same, but they can be fixed with
>      a little more code.

Thanks for your explanation. I see what you mean.

I guess it was just from a pure (C) code level point of view then, 
considering "if" or "?:" as "conditional branch" as is, without 
regarding what's happening at the lower levels when compiling. And 
possibly not regarding the meaning of "conditional branch" in other 
contexts.

So I guess I will revoke my inspiration then and go for Ulis proposal 
(using and if including the size comparison).

- Jonas