llvm dev - Sep 2021 - Status of conflicting inline IR attributes on declaration vs call

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210903/67ded2c3/attachment-0001.html>

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