bug: cannot apply pre-planned n-dimensional FFTs to Fortran-ordered views

If cupyx.scipy.fftpack.get_fft_plan is used to create a plan from a Fortran-ordered array and this plan is later applied to a Fortran-ordered view, the result will either fail with an unexpected shape or potentially give incorrect results.

This is due to an internal copy of the view that does not respected contiguity (PR forthcoming).

The issue does not apply to 1D transforms, only to those use PlanNd via _exec_fftn.

Conditions

CuPy version: 7.0.0 CUDA Root : /usr/local/cuda CUDA Build Version : 10010 CUDA Driver Version : 10010 CUDA Runtime Version : 10010 cuBLAS Version : 10201 cuFFT Version : 10101

Reproduce

The following code illustrates the problem. The issue is caused by an internal copy in _exec_fftn which does not respect array contiguity.

import cupy
from cupy import testing
import cupyx.scipy.fftpack

shape = (32, 16, 4)
dtype = cupy.complex64
data_order = 'F'

a = testing.shaped_random(shape, cupy, dtype)
if data_order == 'F':
    a = cupy.asfortranarray(a)
    sl = [Ellipsis, 0]
else:
    sl = [0, Ellipsis]

# transform a contiguous view without pre-planning
view = a[sl]
expected = cupyx.scipy.fftpack.fftn(view)

# create plan and then apply it to a contiguous view
plan = cupyx.scipy.fftpack.get_fft_plan(view)
with plan:
    out = cupyx.scipy.fftpack.fftn(view)
testing.assert_allclose(expected, out)

The above should work, but instead fails with:

ValueError: The CUFFT plan and a.shape do not match: plan.shape = (16, 32), expected_shape=(32, 16), a.shape = (32, 16)

[grlee77]

I feel like we didn’t test enough F-order arrays in CuPy’s FFT tests

There are some, but I don’t think there were any where the Fortran-ordered data was a view as opposed to an array. That is now remedied in #3034

I think there is also a more general issue that the tests of plan attributes in _exec_fftn only considers the dtype and shape, but ordering/strides info should probably also be validated. I think that may require storing additional information in the PlanNd object, itself though so probably better suited to a follow up to #3034 rather than within that PR.

[grlee77]

Thanks for looking into adding R2C and C2R cases. If you want to give it a try along with that work, it would be great! I think for the purposes of the PlanNd class, we probably just need to store the input/output strides as an attribute to complement the existing shape attribute.