Re: [LAD] gcc and pointer aliasing... missing optimizations in some cases

On Tue, Dec 22, 2009 at 05:55:08PM +0100, torbenh wrote:
>
> hi...
>
> i discovered yesterday, that gcc cant optimize something like:
>
> -----------------------------------------------------------------------
> class Ramp
> {
> private:
> float _phase;
> float _omega;
> public:
> Ramp();
> float process()
> {
> _phase += _omega;
> return _phase;
> }
> };
>
> Ramp osc_block;
>
>
> int process( jack_nframes_t nframes, void *arg )
> {
> int i;
>
> float * __restrict__ buf = (float *) jack_port_get_buffer( out_port, nframes );
>
> for( i=0; i<nframes; i++ ) {
> buf[i] = osc_block.process();
> }
> }
> -----------------------------------------------------------------------
>
> the __restrict__ on buf is not enough to convince gcc that writing to
> buf[i] doesnt clobber _phase or _omega;
>
> i am trying to make a case here, that something stronger than
> __restrict__ is needed which allows the programmer to state that a
> pointer really doesnt alias to anything.
>
> of course the gcc guys say "wont happen" ...
> so the question is whether we have enough need for this in the dsp
> scene... and maybe some political power ?
>
> am i totally wrong and such idioms arent of much use ?

maybe i should have posted the resulting code:

.L5:
        movss osc_block+4(%rip), %xmm0
        addss osc_block+8(%rip), %xmm0
        movss %xmm0, osc_block+4(%rip)
        movss %xmm0, (%rax,%rdx,4)
        addq $1, %rdx
        cmpl %edx, %ebx
        ja .L5
.L7:
        popq %rbx
        ret
>
>
>
> --
> torben Hohn
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev