[llvm-dev] Status of conflicting inline IR attributes on declaration vs call

[Johannes Doerfert via llvm-dev]

I would allow it and give call sites precedence. That will require to 
modify a little bit of code
but we already have getters for call site attributes that work 
differently (maybe accidentally but anyway).

~ Johannes

On 9/3/21 11:15 AM, Danila Malyutin via llvm-dev wrote:
> Hello,
> I'd like to clarify the behavior of LLVM in presence of inline-related attribute annotation on both declaration and the function call, specifically if it differs.
> Currently, it looks like LLVM would always inline the function if it sees 'alwaysinline' attribute on either the call or the declaration, ignoring the 'noinline':
> https://godbolt.org/z/r4e837dj5
> https://godbolt.org/z/4xnoKz978
>
> However, this seems purely accidental (related to how hasFnAttr works), so I wonder if the IR such as in above cases is considered correct.
> I can see it being useful for something like https://lists.llvm.org/pipermail/cfe-dev/2018-September/059232.html , but at the moment the inliner behavior appears inconsistent.
> So, what are the IR guarantees regarding the (no|always)inline attributes? If the programs linked above are incorrect, should there be a verifier check to guard against such IR?
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev