[PATCH] Invariants (and Assume Aligned) - Clang

hfinkel at anl.gov hfinkel at anl.gov
Wed Jul 16 17:05:00 PDT 2014


================
Comment at: docs/LanguageExtensions.rst:1267-1269
@@ +1266,5 @@
+
+The boolean argument to this function is defined to be true. The optimizer may
+analyze the expression used to compute the argument and deduce from that
+information used to optimize the program. If the condition is violated during
+execution, the behavior is undefined.
----------------
hfinkel at anl.gov wrote:
> hfinkel at anl.gov wrote:
> > Richard Smith wrote:
> > > You should indicate whether and when the condition is evaluated here. IIRC, MS' `__assume` does not evaluate its argument, so if this builtin differs from that we should be explicit about that difference.
> > Interesting point. MS's documentation says, "no code is generated", but does not otherwise specify the semantics of what is done with the arguments. With the LLVM intrinsic, although IR is generated, no assembly is generated.
> > 
> > Are you asking whether __assume is more like decltype? Or could __assume(*a > 0) trap if a were nullptr? I'm pretty sure that the answers are no and yes, respectively. MS's documentation specifically talks about using __assume as a production-build replacement for assert, and I assume so must evaluate its inputs in a similar-enough way to make that workable.
> After writing that, it occurred to me that whether or not assert evaluates its arguments depends on the preprocessor state, so there is little to infer from that comparison.
> 
> What is true is that MS has a compiler warning: C4557 (The value passed to an __assume statement was modified.) which triggers on code like __assume(i++).
> 
echristo just confirmed for me on IRC that __assume does not evaluate its arguments. I'll need to filter for side effects.

http://reviews.llvm.org/D149






More information about the cfe-commits mailing list