José Fonseca pisze:
> 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.
>
>
If I try to compile this:
__assume(lalala);
I get:
error C2065: 'lalala' : undeclared identifier
On the other side, the compiler is going to be serious about the
assumptions inside __assume(), and if they happen to be false, the
application can behave not as expected. This is against current gallium
paradigm, where we put assertions, but also do the same check in
non-debug builds to early out from a function or provide default values
(e.g. in switch-case statements).
------------------------------------------------------------------------------
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
