`overwrite_x=True` in cupyx.scipy.fft* doesn't do in-place transform for contiguous views

Reproducer:

>>> import cupy as cp
>>> import cupyx.scipy.fftpack as cufft  # can also use cupyx.scipy.fft
>>> a = cp.random.random((64, 128, 128))+1j*cp.random.random((64, 128, 128))
>>> a.data.ptr
140130136358912
>>> b = a[:16, ...]  # create a C-contiguous view
>>> b.flags
  C_CONTIGUOUS : True
  F_CONTIGUOUS : False
  OWNDATA : False
>>> b.data.ptr  # this is the same as a's
140130136358912
>>> b = cufft.fftn(b, overwrite_x=True)
>>> b.data.ptr  # expected to unchanged
140130041987072

This behavior is not expected, since the FFT of a contiguous view should (and can) be done in-place. (BTW, it doesn’t matter whether a precomputed plan is used or not.) The underlying reason for the unexpected behavior is, curiously, the same for #3033:

This is due to an internal copy of the view that does not respected contiguity

This behavior is also against what we suggested in the doc (in a loose sense): https://github.com/cupy/cupy/blob/016e4ce34723d44a7af613a76acf0baba53b6d3d/docs/source/reference/fftpack.rst#L36 So we fix either the doc or the code. My preference is the latter, as it doesn’t seem to be hard at first glance.

[toslunar]

It’s probably a good practice to align undocumented details with SciPy. For the in-place FFT, however, I would recommend

b[...] = cufft.fftn(b, overwrite_x=True)

if I were sure that x[...] = x has negligible cost in CuPy. The document of scipy.fft.fft says

When overwrite_x=True is specified, the memory referenced by x may be used by the implementation in any way. This may include reusing the memory for the result, but this is in no way guaranteed. You should not rely on the contents of x after the transform as this may change in future without warning.

After #3034, the topic I’m interested in is

• the performance of x[...] = x, or
• the “in-place” feature as in cuFFT, which is more than overwrite_x in SciPy.

[leofang]

Ah, thanks for your thoughts @toslunar. The recommended usage

b = cufft.fftn(b, overwrite_x=True)

was introduced in #2035. I think the original discussion was in #1988. Given our internal implementation, I think this does lead to an in-place FFT when possible. b[...] = b is just an overkill for this case.

But you’re right that in SciPy overwrite_x=True does not guarantee in-place transforms. I think in the past someone (me? don’t remember…) did raise this point and proposed adding a new flag like in_place=True, but my (likely inexact) impression was that there was a strong pushback. If you think a relaxation for the alignment of function signatures is acceptable, I would definitely appreciate it 🙏