So there is a concern that some of these helper functions should remain in the implementation so that they can be inlined efficiently in the internal ggml code - some of them can be called extensively in hot loops. ggml_is_view() specifically does not seem to fall in this category, but I think it would be a good time to introduce a pattern to fix this more generally.

I think we can do the following:

• Add ggml_aux_is_view() to public API (ggml.h) with implementation in ggml.c
• Move ggml_is_view() implementation to ggml-impl.h
• Make ggml_aux_is_view() implementation simply call ggml_is_view() (i.e. it will be inlined)

This way, internal ggml code will continue to use the inlined ggml_is_view() which is now located in ggml-impl.h. User code can call ggml_aux_is_view() which has the overhead of a function call.

With this new pattern established, we can continue to migrate the rest of the auxilary calls, such as ggml_is_transposed(), ggml_is_contiguous() etc. WDYT?

Yes, this is the best solution, inline for performance and an auxiliary for API.

The only shortcoming is that API names become longer with _aux_.... So I suggest to interchange the use of ggml_is_view() and ggml_aux_is_view(). This also paves the way for ggml_is_transposed(), etc: API can be kept unchanged and ggml_aux_is_transposed() can be used internally for performance.

The only shortcoming is that API names become longer with aux.... So I suggest to interchange the use of ggml_is_view() and ggml_aux_is_view(). This also paves the way for ggml_is_transposed(), etc: API can be kept unchanged and ggml_aux_is_transposed() can be used internally for performance.

Yes, it won't be a breaking change this way. Though it would require a massive change in the internal ggml implementation to switch to the aux calls. But at the same time, it can be done incrementally. So your suggestion might be the better option indeed - let me give this a bit of more thought.