On 10/2/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > <snip> > > > > Yes I do see the 0RCR or 0000R case. For example when I change the QA > code > > to use stack allocation for the input (uncommenting a piece of code > that > > was originally there, lines 110 and 111 in the QA code from trunk) the > check > > will fail. > > OK, I'm not surprised by that. I wouldn't consider that a problem, > unless we get in the habit of calling this with stack allocated > input. It could of course be worked around with an attribute((...)) > on the array definition.
agreed. But I am not sure placing a restriction (no stack allocation) makes sense. > In the production code, I.e., where you are seeing problems (was it > around gri_mmse_fir_interpolator?), do you see the alignment > problem occur? In the production code the "input" is declared in gr_mpsk_receiver_cc.h line 300 gr_complex d_dl[2*DLLEN]; http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/lib/general/gr_mpsk_receiver_cc.h If so, I think we should fix the caller. If the calling site is using > stack or heap allocated data, we should fix it there. If it's using > input passed to it by "work" or "general_work", they are already > aligned. In any case, we should add a check at the site of the call > to the SSE code that checks the alignment and raises an exception in > the bad cases. Of course the SSE code could be modified to handle the > other two alignment cases, but I'd like to know the performance cost > of doing it that way before committing to that path. I agree. A check in the SSE code will be required if addressed by a caller fix, else someone in the future will repeat the same effort we are going through today. Summary question: is there an alignment problem when called from the > non-QA code? If so, where? Yes Line 300 of gr_mpsk_receiver_cc.h Tim > Eric >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
