<div dir="ltr">Thank you for your feedback Johannes.<div>Please see my comments below.</div><div><br><div><b><u>Regarding compiler hint:</u></b></div><div>We do not have any short term plan to use that compiler hint in the optimizations.</div><div>But, we would like to hear more from the community about that. </div><div>Which analysis or optimizations can use that hint?</div><div>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".</div><div>That's why we think that this hint can be used in improving data-flow analysis.</div><div><br></div><div><b><u>Regarding renaming to inaccessiblecodeonly:</u></b></div></div><div>We are totally fine to rename it to something else that is easy to understand.</div><div>GCC name for that attribute is already confusing as leaf typically means no function call at all.</div><div>But GCC manual states that leaf functions can actually call other functions, weird!</div><div>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.</div><div>Function that is annotated with a leaf attribute cannot call back the functions in its caller's translation unit.</div><div>So from that perspective, do you think inaccessiblecodeonly makes more sense or not?</div><div><br></div><div>Best,</div><div><br></div><div>Gülfem</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 27, 2020 at 5:54 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com" target="_blank">johannesdoerfert@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Cool!<br>
<br>
<br>
On 10/27/20 7:36 PM, Gulfem Savrun Yeniceri via llvm-dev wrote:<br>
> Hi all,<br>
><br>
><br>
> Introduction:<br>
><br>
>     -<br>
><br>
>     This RFC proposes adding __attribute__((leaf)) support into Clang/LLVM<br>
><br>
><br>
> Motivation:<br>
><br>
>     -<br>
><br>
>     GCC supports __attribute__((leaf)) as an optimization hint described in:<br>
><br>
> <a href="https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Function-Attributes.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Function-Attributes.html</a><br>
><br>
>     -<br>
><br>
>     Fuchsia uses leaf attribute in syscalls, but this attribute is currently<br>
>     only supported in GCC.<br>
>     -<br>
><br>
>     We would like to implement support for this attribute in Clang/LLVM as<br>
>     well.<br>
><br>
><br>
>     -<br>
><br>
>     This support can benefit Clang/LLVM in two ways:<br>
>     -<br>
><br>
>        Achieve feature parity with GCC<br>
>        -<br>
<br>
So far this all makes sense to me.<br>
<br>
<br>
>        Compiler hint to improve data-flow analysis<br>
><br>
Could you give an example where we would use the information.<br>
And do you have any plans to provide code that uses the information <br>
yourself?<br>
<br>
<br>
> High Level Design (WIP):<br>
><br>
>     -<br>
><br>
>     Support __attribute__((leaf)) in Clang<br>
>     -<br>
><br>
>     Add a new LLVM IR attribute called nocallback<br>
>     -<br>
><br>
>     Modify Clang code generator to generate nocallback attribute for leaf<br>
>     attribute<br>
>     -<br>
><br>
>     We choose the name nocallback instead of leaf to avoid confusion. Leaf<br>
>     attribute does not necessarily mean leaf function in the sense that it does<br>
>     not call any other functions. As stated in GCC manual, leaf functions are<br>
>     not allowed to enter their caller's translation unit.<br>
<br>
I'm a little worried about the name because it could be confusing in<br>
the presence (or absence) of !callback metadata<br>
   <a href="https://llvm.org/docs/LangRef.html#callback-metadata" rel="noreferrer" target="_blank">https://llvm.org/docs/LangRef.html#callback-metadata</a><br>
<br>
Without thinking about it too much, the GCC documentation reminds me a <br>
lot of<br>
`inaccessiblememonly` in LLVM-IR. Maybe this could be <br>
`inaccessiblecodeonly`?<br>
<br>
Again, the latter is just an idea ;)<br>
<br>
<br>
><br>
><br>
> Please let us know about your thoughts regarding this RFC.<br>
><br>
> I also prepared a patch, so please let us know if you have any feedback.<br>
><br>
> <a href="https://reviews.llvm.org/D90275" rel="noreferrer" target="_blank">https://reviews.llvm.org/D90275</a><br>
<br>
The patch is incomplete but the idea is clear, once this is settled we can<br>
do a proper review there :)<br>
<br>
<br>
~ Johannes<br>
<br>
<br>
><br>
><br>
> Best,<br>
><br>
><br>
> Gülfem<br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>