22 Dec
2009
22 Dec
'09
12:54 p.m.
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 ?
--
torben Hohn
22 Dec
22 Dec
1:40 p.m.
New subject: 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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--
torben Hohn
3:21 p.m.
New subject: gcc and pointer aliasing... missing optimizations in some cases
On Tue, 22 Dec 2009, torbenh wrote:
class Ramp
{
private:
float _phase;
float _omega;
public:
Ramp();
float process()
{
_phase += _omega;
return _phase;
}
};
Is the problem that _phase and _omega get reloaded from
memory every time they're used?
Would it not work to declare process() as:
float process() __restrict
{ ... }
Thus telling the compiler that `this` is not an alias when
process() is called.
Or perhaps:
int process( jack_nframes_t nframes, void *arg )
{
int i;
float * __restrict__ buf = (float *) jack_port_get_buffer( out_port, nframes );
Ramp * __restrict__ o = &osc_block;
for( i=0; i<nframes; i++ ) {
buf[i] = osc_block.process();
Change to:
buf[i] = o->process();
-gabriel
4:11 p.m.
New subject: gcc and pointer aliasing... missing optimizations in some cases
On Tue, 22 Dec 2009, Gabriel M. Beddingfield wrote:
Thus telling the compiler that `this` is not an alias
when
process() is called.
On second thought... since those didn't work for me,
perhaps part of the problem is that osc_block is a global
variable, and thus there's no way to prove __restrict__ on
it.
-gabriel
8:03 p.m.
New subject: gcc and pointer aliasing... missing optimizations in some cases
On Tue, Dec 22, 2009 at 02:11:23PM -0600, Gabriel M. Beddingfield wrote:
On Tue, 22 Dec 2009, Gabriel M. Beddingfield wrote:
fields of structs are not unaliased, even when the pointer to the struct
is __restrict__
--
torben Hohn
Thus telling the compiler that `this` is not an
alias when
process() is called.
On second thought... since those didn't work for me, perhaps part of
the problem is that osc_block is a global variable, and thus there's
no way to prove __restrict__ on it.
-gabriel 
26 Dec
26 Dec
5:51 a.m.
New subject: gcc and pointer aliasing... missing optimizations in some cases
Thus telling the compiler that `this` is not an alias
when
process() is called.
On second thought... since those didn't work for me, perhaps part of
the problem is that osc_block is a global variable, and thus there's
no way to prove __restrict__ on it.
-gabriel
27 Dec
27 Dec
2:40 a.m.
New subject: gcc and pointer aliasing... missing optimizations in some cases
On Sat, Dec 26, 2009 at 10:50:40AM +0100, Tim Blechmann wrote:
fields of structs are not unaliased, even when the pointer to the struct
is __restrict__
did you check http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14187?
sure. its marked as fixed, and it seems to be fixed.
the thing i am talking about is not a bug.
--
torben Hohn
Thus telling
the compiler that `this` is not an alias when
process() is called.
On second thought... since those didn't work for me, perhaps part of
the problem is that osc_block is a global variable, and thus there's
no way to prove __restrict__ on it.
-gabriel
5395
days inactive
5400
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (3)
-
Gabriel M. Beddingfield -
Tim Blechmann -
torbenh