Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-15 11:43:15


From: Simon Buchan <simon_at_[hidden]>
> Marcin Kalicinski wrote:
> >
> > Have you considered modifying BOOST_ASSERT to use __assume on MSVC?
> >
> > Briefly speaking __assume(expr) is a hint for optimizer that 'expr'
> > evaluates to nonzero. It can help optimize the code. Standalone use of
> > __assume is not recommended because compiler does not check if the
> > assumption is correct, and if it isn't the program is ill formed. But it
> > fits perfectly in ASSERT macro. This way putting many ASSERTs will not only
> > help to verify the code - it will also help the optimizer. Wow!
> <snip>
> I don't get it, isn't the point of assert that it DOES check them? Or

The point is that a violated assertion makes the program die. It
isn't supposed to happen. However, since assertions are often
used only in debug builds, they only help if you run a debug
build. Thus, if you write assertions, but your clients only run
release builds, they don't help much.

Given that the asserted condition holds, then telling the
compiler about that condition gives the compiler information it
might be able to use to optimize better. IOW, putting __assume()
in the non-debug assertion means, effectively, "assuming that the
asserted condition is true (verified in debug builds by an
assertion), you may apply any additional optimizations you might
otherwise have skipped."

If the checking of a debug build isn't brought to bear, then the
asserted condition may well be violated anyway. So, whether you
get bad results due to "overly agressive" optimization or due to
assumptions made by the code following the assertion hardly
matters.

I think the addition is a great idea. Do other compilers offer
anything similar? I'd hate to miss this opportunity on other
platforms.

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk