On 10/2/07, Eric Blossom <address@hidden> 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?
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