[llvm] [InlineCost] Never inline functions with incompatible target features (PR #205113)

[Aiden Grossman via llvm-commits]

boomanaiden154 wrote:

> I'll look into this one. I think that we may want to just completely ignore these ARM architecture features for inlining? As far as I can tell, these architecture features are not actually used for anything, they just exist to imply other features that matter (like HasVxxxOps).

I don't think we can just completely ignore them. From my understanding, it would still be illegal to inline a function marked `v8a` into a function marked `v7a` for example, but I'm not an ARM expert.

> I haven't looked very closely, but I think that one was just a bug in X86's areInlineCompatible? It shouldn't error in the frontend, because it's supposed to inline. The underlying issue (inline assembly affecting ABI checks) has been fixed.

Yes, the specific case there was already fixed in the X86 TTI implementation.

> So I'm a bit unclear on what warning you actually want to implement? Do you want to promote optimization remarks for always inline failures to compiler warnings?

Yes, that was (the beginnings of) the idea. We already do it in some cases (where clang can directly see the attributes and that they are trivially incompatible). It would make diagnosing potential fallout from this change much easier. Although the implementation might be tricky because we probably don't want to diagnose things like ICP promoting `always_inline` functions with differing target attributes.

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