On Tue, Jan 5, 2010 at 2:40 PM, torbenh <torb...@gmx.de> wrote:
>
> hi...
>
> i am new to this list.
>
> i am trying to something like:
>
> struct Ramp
> {
> float phase;
> inline float process() { return phase++; }
> } ramp;
>
> void fill_buffer( float *buf, size_t nframes )
> {
> for( size_t i=0; i<nframes; i++ )
> buf[i] = ramp.process()
> }
>
> the goal is to chain several of such Ramp structs together via
> templates. so that i can model dsp graphs, but have it all inlined into
> the loop.
>
> however the stores to phase cant be moved out of the loop due to
> aliasing. but that is one of the points to do this whole exercise.
>
> this simple case can be optimized when i use -fargument-noalias-anything
> and:
>
> void fill_buffer( float *buf, size_t nframes )
> {
> for( size_t i=0; i<nframes; i++ )
> *(buf++) = ramp.process()
> }
>
> but things start to break again, when i add:
>
> struct Sample
> {
> unsigned int pos;
> float *sample;
> inline float process() { return sample[pos++]; }
> }
>
>
> __restrict__ is of no help here. which leads me to the question whats
> the point of a restricted this pointer ? members of structs arent
> unaliased by a __restrict__ pointer to the struct.
>
> my favourite solution would be __noalias__ ... msvc has that.
> but -fnoalias would make me happy too.
>
> i havent read much of the gcc code yet, so i am not sure what i need to
> patch.
>
> refs_may_alias_p_1() is my current bet though.
The -fno-alias-X things do not make much sense for user code (they
have been historically used from Frontends). If restrict doesn't work
for you (do you have a testcase that can reproduce your issue?)
then you probably need to wait for IPA pointer analysis to be
fixed in GCC 4.6.
Richard.
> --
> torben Hohn
>
