The use of __restrict pointers in the DSP subsystem

[yperess]

During review of #51059, there was a discussion about adding the __restrict attribute to the DSP API.

Background

The __restrict attribute when applied to a function argument such as int my_func(int * __restrict x, int * __restrict y) tells the compiler that x and y don't point to the same object. This allows the compiler to perform some optimizations that would otherwise be impossible. When dealing with the DSP library, we will have things like add(res, lhs, rhs, count). If __restrict is used, that means that we can't replicate things like a += b since a can't be both the res and lhs. Instead we would need to create a temporary buffer of size count, perform the addition, then copy the result from the temporary buffer back into a. Effectively, __restrict is a choice between potential performance vs memory use.

Option 1

We disallow __restrict and keep the API simple. We will lose some performance gains under some architectures.

Option 2

Add __restrict and document that a += b is undefined.

Option 3

We add a Kconfig option for DSP_USE_RESTRICT_POINTERS which will add the __restrict into the function signatures. This wold allow apps to choose on their own, but has the downside that any common library or use of the DSP in Zephyr will need to either be incompatible, always assume __restrict, or provide 2 different implementations (this would be difficult to manage).

[ruuddw]

To me the __restrict is more an (optional) implementation detail, that helps the compiler optimizations (like the AGU option we have for ARC). So instead of allowing or disallowing __restrict, the discussion/restriction should IMHO be on allowing input and output buffers to overlap (in-place processing) or not.
Implementations that optimize using __restrict may still support the in-place processing (behavior is undefined, not forbidden/broken). Obviously some warning and explicit testing would be required in that case to ensure the optimized implementation adheres to the defined in-place semantics.

That said, my vote would be for the more restricted semantics as it allows for more implementations. I'm still waiting to hear about examples/use-cases that really need or benefit from the in-place. Often operations are chained anyway, so it could be like c = a + b; a = c * b, etc. with only a single extra temporary buffer and no copying.