[llvm-dev] [RFC] Leaf Attribute Support in Clang/LLVM

[Johannes Doerfert via llvm-dev]

Cool!


On 10/27/20 7:36 PM, Gulfem Savrun Yeniceri via llvm-dev wrote:
> Hi all,
>
>
> Introduction:
>
>     -
>
>     This RFC proposes adding __attribute__((leaf)) support into Clang/LLVM
>
>
> Motivation:
>
>     -
>
>     GCC supports __attribute__((leaf)) as an optimization hint described in:
>
> https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Function-Attributes.html
>
>     -
>
>     Fuchsia uses leaf attribute in syscalls, but this attribute is currently
>     only supported in GCC.
>     -
>
>     We would like to implement support for this attribute in Clang/LLVM as
>     well.
>
>
>     -
>
>     This support can benefit Clang/LLVM in two ways:
>     -
>
>        Achieve feature parity with GCC
>        -

So far this all makes sense to me.


>        Compiler hint to improve data-flow analysis
>
Could you give an example where we would use the information.
And do you have any plans to provide code that uses the information 
yourself?


> High Level Design (WIP):
>
>     -
>
>     Support __attribute__((leaf)) in Clang
>     -
>
>     Add a new LLVM IR attribute called nocallback
>     -
>
>     Modify Clang code generator to generate nocallback attribute for leaf
>     attribute
>     -
>
>     We choose the name nocallback instead of leaf to avoid confusion. Leaf
>     attribute does not necessarily mean leaf function in the sense that it does
>     not call any other functions. As stated in GCC manual, leaf functions are
>     not allowed to enter their caller's translation unit.

I'm a little worried about the name because it could be confusing in
the presence (or absence) of !callback metadata
   https://llvm.org/docs/LangRef.html#callback-metadata

Without thinking about it too much, the GCC documentation reminds me a 
lot of
`inaccessiblememonly` in LLVM-IR. Maybe this could be 
`inaccessiblecodeonly`?

Again, the latter is just an idea ;)


>
>
> Please let us know about your thoughts regarding this RFC.
>
> I also prepared a patch, so please let us know if you have any feedback.
>
> https://reviews.llvm.org/D90275

The patch is incomplete but the idea is clear, once this is settled we can
do a proper review there :)


~ Johannes


>
>
> Best,
>
>
> Gülfem
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev