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
> [email protected]
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
