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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201027/f7c0a620/attachment.html>

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

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

On Tue, Oct 27, 2020 at 5:54 PM Johannes Doerfert <
johannesdoerfert at gmail.com> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201028/3a392d97/attachment.html>