[clang] [clang][SME] Ignore flatten for callees with mismatched streaming attributes (PR #116391)

[Sander de Smalen via cfe-commits]

sdesmalen-arm wrote:

> Do we really need to do this in the frontend? The inliner itself should be doing safety checks.

The inliner avoids any safety checks when `alwaysinline` is specified, and this can't easily be changed (I previously raised this on [Discourse](https://discourse.llvm.org/t/rfc-avoid-inlining-alwaysinline-functions-when-they-cannot-be-inlined) and did some experimentation refactoring LLVM inlining to distinguish between the two cases, but never had a chance to properly follow this up)

At the moment, LLVM has three ways to do inlining:
* `<no specific attribute>` means LLVM will try to inline only if profitable.
* `inlinehint`, means that LLVM should favour inlining in its cost model, but doens't inline when `areInlineCompatible` returns `false`)
* `alwaysinline`, means that LLVM disregards the cost-model and always inlines a function (even when `areInlineCompatible` would otherwise return `false`).

The last one, `alwaysinline` has different semantics from the corresponding C++ attribute. The C++ attribute means "must inline" where if it cannot inline, the compiler must error. Unfortunately `alwaysinline` is chosen to implement the C++ attribute as well, which leads to issues that we had to work around in Clang (see #77936 and #100740 that emit a diagnostic/warning in Clang if inlining may not be possible, which has to be conservative). We actually want to be able to distinguish "always inline if possible (ignoring any cost-model)" and "always inline and fail if not possible", but I think ideally this would require a new attribute to LLVM.

For the immediate bug addressed in this PR, the route chosen is to avoid adding `alwaysinline` on calls when we know that the called functions are not (at compiletime known to be) compatible to be inlined.

https://github.com/llvm/llvm-project/pull/116391