On Thu, Sep 17, 2015 at 1:56 AM, West, Nathan <n...@ostatemail.okstate.edu> wrote: > > >> I've nagged people about this before, but I'd like to make this an >> official thing: Put this into the VOLK docs (i.e. state in the contract >> that in- and output buffers may be the same) and then include that in >> the unit tests, so we don't end up with some arcane ISA that will not >> allow this. In-place VOLK calls are very useful for many blocks, and >> I've shied away from using them myself in the past just because I wanted >> to be sure they'll work in the future. >> >> M >> > > I think it's reasonable to make a contract that in and out buffers may be > the same and to document that. > > Putting it in the QA is a tad more difficult since there are cases where > kernels have multiple input buffers and other cases where kernels have > multiple output buffers-- which ones do we test? For single input and > single output buffers that's reasonable, but outside of that it becomes a > large number of permutations. There is a GCC keyword _restrict (or > _restrict_) that suppsedly lets GCC do some optimizations if pointers are > not aliased. Since we never use this keyword it's OK to use the same buffer > unless there's some funky kernel (branch_16i_branch_4_state_8 comes to > mind) in which case you probably are aware of what you're doing. > > Finally, I want to clarify what I meant by in-place operations. I was > referring to the type of signature Dennis referred to: > volk_32f_s32f_multiply(float* buffer, float scalar, num_points) where the > input and output buffers are explicitly the same and we always write the > result in the memory location where the input came from. I don't consider > the use of kernels such as the existing log2 with input buffers == output > buffers to be in-place since the compiler is not aware that they are > pointing to the same memory location. > > nw >
Just to echo a little bit here: documenting things is certainly useful, but rigorously testing of all corner cases in QA code is hard. I'm of a similar mind to avoid VOLK kernels which are *explicitly* in place, since that restricts their usefulness (e.g. for blocks that are basically just wrappers to VOLK kernels, we *don't* want to do things in-place, since we're moving from the input buffer to the output buffer), especially when for those cases which do want to do things in-place, passing the same pointer in 'just works' (note: I believe for most existing kernels this is currently true, but you should definitely test this any time you try!). And for those interested in the technical minutia of the restrict keyword vs. pointer aliasing, and in-place operations, I highly recommend: http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html Signing the contract is not optional when calling a function that uses the restrict/_restrict/__restrict__ keyword! Also, note that restrict became a full-fledged keyword in C99 (although _restrict and __restrict__ are still supported by GCC, and I believe Clang respects __restrict__, and I'll note that MSVC only started to support it in VS2015). -- Doug Geiger doug.gei...@bioradiation.net
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
