[LLVMdev] [cfe-dev] Disable Short-Circuit Evaluation?

[Sean Middleditch]

2011/10/10 Konstantin Tokarev <annulen at yandex.ru>

>
>
> 10.10.2011, 18:29, "David A. Greene" <greened at obbligato.org>:
> > Justin Holewinski <justin.holewinski at gmail.com> writes:
> >
> >>  int globalIndexY2 = get_group_id(1)*186 + 6*get_local_id(1) + 2 + 1;
> >>  bool valid2       = validX && globalIndexY2 >= 4 && globalIndexY2 <
> 3910;
> >>
> >>  Clang, even at -O0, is performing short-circuit evaluation of these
> >>  expressions, resulting in a fair number of branch instructions being
> >>  generated.
> >
> > It has to.  This is the semantics of C.  Short-circuiting is used to
> > defend against all sorts of undefined behavior in real code.
>
> More precisely, && and || are sequence points (though in C++ they may not
> be
> sequence points if respective operator is overloaded)
>

Sequence points don't really come into play in a meaningful way in code like
that given above.  In the example given, each expression is without side
effects, and none of the latter expressions are dependent on the
predecessors (no "ptr != NULL && *ptr == value" sorts of things).

noting that boolean values are either exactly 1 or 0, this statement:
  bool valid2       = validX && globalIndexY2 >= 4 && globalIndexY2 < 3910;
is equivalent to this statement:
  bool valid2       = validX & globalIndexY2 >= 4 & globalIndexY2 < 3910;
assuming no operator overloading or anything else crazy going on.

There may be some non-trivial work involved in converting the >= and < tests
into boolean values depending on the architecture, which can seriously
affect the value of such a transformation.  Also worth noting is that
globalIndexY2 is known to be in a register from the previous line of code
and so there is no load instruction or any chance of a cache miss being
avoided by a short-circuit branch, so it really boils down to the cost of
the extra instructions vs the cost of the eliminated branches.
-- 
Sean Middleditch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111011/82db90f6/attachment.html>