[sldev] [VWR] Vectorization on i386?

[Dzonatas]

Callum Lerwick wrote:
> On Mon, 2007-12-03 at 16:07 -0600, Callum Lerwick wrote:
>   
>> By "enabled" in this thread I mean enabling the SSE code at *runtime*.
>> That is the problem. Which is what I have fixed. I'm not sure what
>> you're meaning by "not enabled", if you're saying its "not enabled" as
>> in "not compiled in at all", you're wrong. :)
>>     
>
> Ooooh wait, more "dur" info. The preprocessor logic in llv4math.h looks
> like this:
>
> #if LL_GNUC && __GNUC__ >= 4 && __SSE__
> #define LL_VECTORIZE 1
>
> So, since LL is clinging to gcc 3, SSE *is* in fact disabled in LL
> builds. But all of us compiling with gcc 4 have been getting SSE. :)
>   

Yep. GCC 3 and 4 handle the default vector type differently. We could 
probably put GCC 3.3+, but it would need a few test runs to make sure it 
still works the same. I believe we dropped all the GCC 4 specific code 
which was added originally to easily support the AltiVec.

LL_VECTORIZE is boolean on to enable the vector code at compile-time. It 
should not have been used to include or exclude truth about processors 
for run-time. We need to trust the run-time detection or fix it if it is 
obviously wrong. The posted plan is to move the viewer to be more 
modular, and the run-time detection needs to be the truth for what are 
the best modules to use.

There was a backwords step taken here.  (Hence, C++ should not use 
#if-defs in static cpp implementation files unless it is for debug 
purposes, but there still is C style found here due to the Coding Style)

For example, this kind of code is preferred:

class gCompiler {
    bool getVectorize() { return( LL_VECTORIZE ); }
    }

Dead-store and Dead-code removal will optimize away code like this:

if( gCompiler.getVectorize() )
    {
    doVectorizationStep();
    }
else
    {
    doNormalStep();
    }


Would that make less 'Dur'?  It is more readable, only one branch is 
actually compiled, and there is the extra type check.

-- 
Power to Change the Void
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/0b505166/attachment-0001.htm