[vsipl++] patch: fix merge conflicts

[Stefan Seefeld]

Jules Bergmann wrote:

> Do you consider FFTM to be 1D or non-1D?

Well, the distinction is only required if we use different alignment
constraints. For planning we use FFTW_UNALIGNED for all but 1D FFT
(i.e. 2D, 3D, as well as M). With assem's patch (and my little fix)
we use Stride_unit_align throughout, which may be overly restrictive,
given that Stride_unit_dense would be perfectly valid for non-1D cases,
so we may end up doing a redundant copy (well, two, actually).

> The reason I ask is ...
> 
> We implement FFTM by planning for a single 1D FFT (we do this, rather
> than planning for multiple 1D FFTs, because distributed data may cause
> the local multiple count to be different from the global multiple count).
> 
> Ideally this single 1D FFT should be planned for aligned data.

Right, understood. We don't do that yet, though this only seems to
require a change to the Fftm_impl constructor's call to Fft_base<>(),
where we would no longer pass FFTW_UNALIGNED.

> We can relax that when the FFT size is not a multiple of the alignment.
>  I.e. if we're doing multiple 257-point FFTs, we can plan for unaligned
> data.
> 
> Does that sound reasonable?

Indeed. Should I add my suggested change above to the patch before checking
it in ?

Thanks,
		Stefan

-- 
Stefan Seefeld
CodeSourcery
stefan at codesourcery.com
(650) 331-3385 x718