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

[torbenh]

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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn