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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
