Re: [boost] BOOST_ASSERT and __assume on MSVC

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-10-04 08:29:23

From: "Peter Dimov" <pdimov_at_[hidden]>
> Rob Stewart wrote:
> > From: Felipe Magno de Almeida <felipe.m.almeida_at_[hidden]>
> >> On 10/3/05, Rob Stewart <stewart_at_[hidden]> wrote:
> >>>
> >>> (Note that __assume(false) is useless, for it is an expression
> >>> that the optimizer cannot use to optimize anything.  So, while I
> >>> understand that you were trying to simplify things for the
> >>> discussion, let's also not lose sight of what is really meant
> >>> when writing __assume(false) in the above examples.)
> >>
> >> I think you're wrong.
> >> __assume(false) means that this code will never be executed, and as
> >> such isnt useless for the optimizer.
> >
> > Hmmm.  I guess you're right.  Still, it only means that the code
> > following __assume(false) can be elided, not any preceeding code,
> > right?
> 
> The preceding code can be elided if the compiler can prove that it doesn't 
> affect the reachability of __assume(false). ++x can, a function call cannot 
> (in general) without whole program optimization. 

We're talking about the optimizer here, so yes, it can do
analysis to prove whether a particular block of code affects
whether __assume(false) can be reached.  However, I was trying to
speak of generalities--which I didn't make clear--such that the
appearance of __assume(false) in a block doesn't mean the entire
block may be elided, including preceeding code.  The optimizer
must prove also that the foregoing statements don't have
observable side effects before eliding them.

In the (elided ;-) example, ++x has a side effect so while it
doesn't affect whether __assume(false) is reached, the optimizer
shouldn't elide the increment unless it can prove that the new
value of x is not used.  Are you suggesting that __assume(false)
would override that?

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;