On Mon, 2009-12-14 at 08:22 -0800, Keith Whitwell wrote:
> On Mon, 2009-12-14 at 08:19 -0800, Keith Whitwell wrote:
> > On Mon, 2009-12-14 at 08:04 -0800, José Fonseca wrote:
> > > On Mon, 2009-12-14 at 05:39 -0800, Keith Whitwell wrote:
> > > > On Sun, 2009-12-13 at 15:27 -0800, Marek Olšák wrote:
> > > > >
> > > > > +static INLINE
> > > > > +void util_blitter_save_fragment_sampler_states(
> > > > > + struct blitter_context *blitter,
> > > > > + int num_sampler_states,
> > > > > + void **sampler_states)
> > > > > +{
> > > > > + assert(num_textures <= 32);
> > > > > +
> > > > > + blitter->saved_num_sampler_states = num_sampler_states;
> > > > > + memcpy(blitter->saved_sampler_states, sampler_states,
> > > > > + num_sampler_states * sizeof(void *));
> > > > > +}
> > > > > +
> > > >
> > > > Have you tried compiling with debug enabled? The assert above fails to
> > > > compile. Also, can you use Elements() or similar instead of the
> > > > hard-coded 32?
> > > >
> > > > Maybe we can figure out how to go back to having asserts keep exposing
> > > > their contents to the compiler even on non-debug builds. This used to
> > > > work without problem on linux and helped a lot to avoid these type of
> > > > problems.
> > >
> > > I wouldn't say without a problem: defining assert(expr) as (void)0
> > > instead of (void)(expr) on release builds yielded a non-negligible
> > > performance improvement. I don't recall the exact figure, but I believe
> > > it was the 3-5% for the driver I was benchmarking at the time. YMMV.
> > > Different drivers will give different results, but there's nothing
> > > platform specific about this.
> >
> > It's not hard to avoid excuting code... For instance we could always
> > have it translated to something like:
> >
> > if (0) {
> > (void)(expr);
> > }
> > (void)(0)
> >
>
> Obviously I would have meant to say something cleaner like:
>
> do {
> if (0) { (void)(expr); }
> }
> while (0)
This only works if expr has no calls, or just inline calls. Using my
earlier example, if very_expensive_check() is in another file then the
compiler has to assume the function will have side effects, and the call
can't be removed.
I'm not sure __assume keyword that Michal mentioned helps. It's more a
hint to the compiler to help him optimize code around the assertion, but
perhaps it helps with the warnings too.
Jose
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
