[PD-dev] d_math.c "break[s] strict-aliasing rules"

[Hans-Christoph Steiner]

On Apr 18, 2007, at 9:13 PM, Miller Puckette wrote:

> Well, I measured the difference and didn't see significant speedup  
> (on an
> imac recently)... eventually it might make a difference, of  
> course.  But
> certain bit-bashing code (the square root thing, but more importantly
> phasor~ and osc~) runs half again faster than any version I've been  
> able
> to write with strict aliasing.

Do you have any info on that test, like which optimizations you tested?

> An alternative would be to special-case the offending code  
> somehow.  This
> could be part of a larger effort to make the DSP code modular so  
> that SSE
> instructions and whatnot could also be "plugged in".  Worth  
> thinking about...

Now that gcc is supporting auto-vectorization, I think it would be  
worth revisiting.  That's what pushed me down this route to begin  
with.  I get the feeling that a lot of C code would just need to be  
massaged a bit in order to get vectorized by gcc. I did have some  
promising results with that, but it was hard to pin down exactly what  
was going on.

.hc

>
> cheers
> Miller
>
> On Wed, Apr 18, 2007 at 07:27:29PM -0400, Hans-Christoph Steiner  
> wrote:
>>
>> Is there any particular reason why it was done this way?  Does any
>> object if  it was fixed?
>>
>> It seems that -fstrict-aliasing is basic to compiler optimization
>> since gcc -O2 enables it.  There has been a lot of work recently in
>> making gcc produce faster code. It would be very nice if we could
>> take advantage of that.  I think -fstrict-aliasing would be a
>> necessary part of that.
>>
>> .hc
>>
>>
>> On Apr 18, 2007, at 4:55 PM, Miller Puckette wrote:
>>
>>> I think there are several places where "strict-aliasing" isn't
>>> followed.  I always compile with -fno-strict-aliasing to prevent
>>> problems.
>>>
>>> cheers
>>> Miller
>>>
>>> On Wed, Apr 18, 2007 at 11:19:20AM -0400, Hans-Christoph Steiner
>>> wrote:
>>>>
>>>> So it seems that this bug in d_math.c is triggered by turning on  
>>>> the
>>>> Apple-recommended optimization flags:
>>>>
>>>> http://sourceforge.net/tracker/index.php?
>>>> func=detail&aid=1692649&group_id=55736&atid=478070
>>>>
>>>> I did notice that there are these warnings in the source.  IIRC,
>>>> optimization generally requires strict aliasing, so it seems that
>>>> these warnings are probably related to the above bug:
>>>>
>>>> d_math.c: In function 'init_rsqrt':
>>>> d_math.c:79: warning: dereferencing type-punned pointer will break
>>>> strict-aliasing rules
>>>> d_math.c: In function 'q8_rsqrt':
>>>> d_math.c:93: warning: dereferencing type-punned pointer will break
>>>> strict-aliasing rules
>>>> d_math.c: In function 'q8_sqrt':
>>>> d_math.c:101: warning: dereferencing type-punned pointer will break
>>>> strict-aliasing rules
>>>>
>>>> Here are the lines in question:
>>>>
>>>> 79:    *(long *)(&f) = l;
>>>> 93:    long l = *(long *)(&f);
>>>> 101:   long l = *(long *)(&f);
>>>>
>>>> Can anyone speak to what's this for and what it can be replaced  
>>>> with
>>>> so as to follow "strict-aliasing rules".  Maybe we could use
>>>> something like this instead (from http://www.cs.tut.fi/~jkorpela/
>>>> round.html ):
>>>>
>>>> #define round(x) ((x) < LONG_MIN-0.5 || (x) > LONG_MAX+0.5 ?\
>>>> error() : ((x)>=0?(long)((x)+0.5):(long)((x)-0.5))
>>>>
>>>> This requires that you have #include <limits.h> and that you  
>>>> have an
>>>> error handling routine called error which is a function of type  
>>>> long.
>>>>
>>>>
>>>> .hc
>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> ---
>>>> ----
>>>>
>>>>                              kill your television
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> PD-dev mailing list
>>>> PD-dev at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> ----
>>
>> All information should be free.  - the hacker ethic
>>
>>
>>
>>
>>
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev



------------------------------------------------------------------------ 
----

If you are not part of the solution, you are part of the problem.