<div dir="ltr">I think this requires changes to the bitcode reader. This has been discussed a bit, see <a href="https://lists.llvm.org/pipermail/llvm-dev/2019-March/131216.html">https://lists.llvm.org/pipermail/llvm-dev/2019-March/131216.html</a>  for example.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 11, 2019 at 5:06 PM LevitatingLion <<a href="mailto:levitatinglion@web.de">levitatinglion@web.de</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"><div>I have a working patch which adds the 'flatten' attribute almost ready, but it breaks the Bitcode/highLevelStructure.3.2.ll test. This is caused by the attribute definition in include/llvm/IR/Attributes.td:<br><br>def Flatten : EnumAttr<"flatten">;<br><br>llvm-dis seems to be unable to correctly decode attributes stored in the bitcode when the new attribute is added. Why does this happen, and how do I fix it?<br><br>Other attributes don't seem to have required any handling of this problem, see <a href="https://reviews.llvm.org/D62766" target="_blank">https://reviews.llvm.org/D62766</a> or <a href="https://reviews.llvm.org/D49165." target="_blank">https://reviews.llvm.org/D49165.</a> Could that be because this is the 65th attribute (so a bitmask indicating all attributes doesn't fit in 64 bit anymore)?<br><br><div class="gmail_quote">On November 5, 2019 7:24:58 PM GMT+01:00, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">I like the proposal to add a new call site attribute, either "flatten" or "always_inline_recursively".<div><br></div><div>I wouldn't want to add an optional depth to the existing always_inline attribute. It already has a well understood meaning.</div><div><br></div><div>Good luck. :)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 2:12 PM LevitatingLion via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">Hi everyone,<br>
<br>
clang currently implements the 'flatten' function attribute by marking<br>
all calls to not 'noinline' functions with 'always_inline'. In effect,<br>
only the first level of calls is inlined, not all calls recursively<br>
(like gcc does).<br>
<br>
We briefly discussed possible solutions on IRC:<br>
<br>
We could add an equivalent LLVM attribute for functions (e.g.<br>
'flatten'). The main problem with this approach occurs when we're<br>
inlining the function marked with 'flatten'. In this case we could<br>
either drop the attribute, move it to the function we're inlining into<br>
(both would lose the scope of the original 'flatten' annotation), or<br>
distribute it to all calls within the 'flatten' function (which would<br>
require a new call site attribute).<br>
<br>
The other approach is to add or modify a call site attribute. We could<br>
add a specific attribute (e.g. 'flatten' or<br>
'always_inline_recursively'), but a more general solution is adding a<br>
new 'depth' parameter to the existing 'always_inline' attribute. When a<br>
call site marked 'always_inline' is inlined, the attribute will then be<br>
duplicated to all new call sites (with decremented depth and only if the<br>
depth is greater than zero).<br>
<br>
With this solution, one problem remains: an 'always_inline' on the call<br>
site is currently stronger than a 'noinline' on the callee. Thus, a<br>
recursive 'always_inline' would ignore 'noinline'. To fix this, we can<br>
make 'always_inline' weaker than 'noinline'. If that breaks backwards<br>
compatibility too much, we could add a second parameter (boolean 'weak'<br>
or 'strong') to 'always_inline'.<br>
<br>
I've never worked on LLVM before, but if someone confirms what the<br>
preferred solution to this is, I will start working on a patch.<br>
<br>
Thanks for your time<br>
LevitatingLion<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>
</blockquote></div></div></blockquote></div>