[macstl-dev] not all rosey in the gcc-4.0.0 land

Glen Low glen.low at pixelglow.com
Tue Jul 5 08:17:24 WST 2005

  • Previous message: [macstl-dev] not all rosey in the gcc-4.0.0 land
  • Next message: [macstl-dev] Note about the YDL benchmarks
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]


Ilya:

On 05/07/2005, at 7:34 AM, Ilya Lipovsky wrote:

>> 3.    The code at line 154 is called from valarray_algorithm.h:60,  
>> there's another place to do 1, 2 and other things to see if this  
>> is where the overoptimization happens. This is where the valarray  
>> is examined so that only the initial sequence is vectorized, while  
>> the tail, left-over elements use a scalar loop (called tail).
>>
>>
>
> Line 60 of valarray_algorithm.h corresponds to comments. It will be  
> very appreciated if you give me the actual chain of invocation.  
> Right now I know 1 thing for sure : the problem does not happen in  
> valarray_altivec.h:154 . I commented out the whole structure and  
> yet the overoptimization still occurs (i.e. it's somewhere earlier  
> in the chain).

Commenting out valarray_altivec.h:154 won't necessarily show anything  
since that's a partial specialization, so if you comment it out the  
compiler simply selects the primary template.

Invocation chain:

valarray_base.h:77 (sum member function)
valarray_algorithm.h:118 (accumulate array dispatcher)
valarray_algorithm.h:87 (accumulate array for chunkable expressions,  
splits into initial segment for vector and tail for scalar)
algorithm.h:397 (STL-like accumulate dispatch)
valarray_altivec.h:154 (STL-like accumulate for Altivec)

The bottom 2 calls were meant to be useable outside of valarrays as a  
straight extension to STL algorithms.
>>

>> FSF gcc 4.0 release is dated 20 April 2005, and I suspect Apple  
>> put in a lot of effort over and beyond that to get it working with  
>> Altivec code for Tiger and Xcode 2.1 -- more's the pity they seem  
>> to be all for switching to Intel. So we may be better off waiting  
>> for 4.0.1 if we can't resolve the overoptimization, and leave only  
>> 3.4.x the supported compiler for YDL at all optimization levels --  
>> according to the gcc.gnu.org site the 4.0 branch has been frozen  
>> as of 13 June in preparation for 4.0.1 release.
>>
>>
>
> I am afraid that we'll have to.
>
> -Ilya
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pixelglow.com/lists/archive/macstl-dev/attachments/20050705/1f3e7dc1/attachment.html

  • Previous message: [macstl-dev] not all rosey in the gcc-4.0.0 land
  • Next message: [macstl-dev] Note about the YDL benchmarks
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the macstl-dev mailing list