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

[Gulfem Savrun Yeniceri via 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>