sdesmalen-arm wrote: > You're effectively saying "this function is non-streaming specific", but we > don't have any way to show this intent beyond using non-streaming specific > intrinsics
A function that has no streaming/streaming-compatible attributes and somehow relies on vscale is 'non-streaming specific'. Otherwise, it should have been a `__arm_streaming_compatible` function. For example, the only way to get the non-streaming vector length is to use a `rdvl/cntb/h/w/d` in a non-streaming context (only for the streaming case there are the `rdsvl/cntsb/..` instructions). If a streaming function requires the non-streaming VL (e.g. for some pointer arithmetic) and would use a utility function (explicitly without the `__arm_streaming` attribute) then it would result in different behaviour when inlining that function in a streaming context. I'm not sure how much of a problem this case is in practice though; it relates to functions that are explicitly written for SVE, but if anyone writes a library for SVE and wants it to be used in a streaming context, they should port their library to be streaming-compatible. Or otherwise accept that the functions won't be inlined (unless they're `always_inline`, in which case it should be an error). https://github.com/llvm/llvm-project/pull/223393 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
