================ 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. ---------------- [email protected] wrote: > [email protected] 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
