[RFC] Leaf Attribute Support in Clang/LLVM

Project Infrastructure LLVM Dev List Archives
#1

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

  • Compiler hint to improve data-flow analysis

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.

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

Best,

Gülfem

#2

Cool!

Hi all,

Introduction:

    -

    This RFC proposes adding __attribute__((leaf)) support into Clang/LLVM

Motivation:

    -

    GCC supports __attribute__((leaf)) as an optimization hint described in:

Function Attributes - Using the GNU Compiler Collection (GCC)

    -

    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 :wink:

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 :slight_smile:

~ Johannes

#3

Thank you for your feedback Johannes.
Please see my comments below.

Regarding compiler hint:
We do not have any short term plan to use that compiler hint in the optimizations.
But, we would like to hear more from the community about that.
Which analysis or optimizations can use that hint?
GCC manual states that “The compiler takes the hint that any data not escaping the current compilation unit can not be used or modified by the leaf function”.
That’s why we think that this hint can be used in improving data-flow analysis.

Regarding renaming to inaccessiblecodeonly:

We are totally fine to rename it to something else that is easy to understand.
GCC name for that attribute is already confusing as leaf typically means no function call at all.
But GCC manual states that leaf functions can actually call other functions, weird!
The reason that we choose nocallback is that leaf attribute does not have any effect for the functions that are defined in the current translation unit.
Function that is annotated with a leaf attribute cannot call back the functions in its caller’s translation unit.
So from that perspective, do you think inaccessiblecodeonly makes more sense or not?

Best,

Gülfem