José Fonseca pisze:
> On Mon, 2009-12-14 at 08:58 -0800, michal wrote:
>
>> 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).
>>
>
> Bummer... that's no good.
>
>
>
On the third hand, we could transform the following idiom
switch (foo) {
case 1:
bar = 22;
default:
assert(0);
bar = 11; /* Safe value. */
}
to use some flavour of assert() that doesn't get substituted with
__assume() on non-debug builds. Something like weak_assert() or
warning(). Then assert() could be used in places where there is no
backup plan and the app is going to crash anyway.
Or... do the opposite and introduce strong_assert() that translates to
__assume() and leave assert() as it is now.
------------------------------------------------------------------------------
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
