<div dir="ltr">Ah I see.<div><br></div><div>I can't think of a way that would help users in any particular way offhand. I hadn't considered exposing it to clang users - do you think there is merit in that?</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 5 Nov 2015 at 16:08 Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Nov 5, 2015 at 11:06 AM, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>> wrote:<br>
> Hi Aaron,<br>
><br>
> I think it must necessarily be exposed to users - clang must add it in<br>
> certain circumstances for example. I don't think this is particularly<br>
> different to many other attributes such as nocapture/nounwind, that are<br>
> exposed to users and can be set by users in exceptional circumstances but<br>
> are primarily inferred by the midend.<br>
<br>
Sorry, I was unclear. I meant to Clang users as a language-level<br>
attribute (e.g., [[clang::norecurse]]), not LLVM users as an IR-level<br>
attribute.<br>
<br>
~Aaron<br>
<br>
<br>
><br>
> James<br>
><br>
> On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>><br>
>> On Thu, Nov 5, 2015 at 10:44 AM, James Molloy via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> > [Adding llvm-dev and re-stating the situation for llvm-dev's benefit]<br>
>> ><br>
>> > RFC: A new attribute, "norecurse".<br>
>> ><br>
>> > In some cases, it is possible to demote global variables to local<br>
>> > variables.<br>
>> > This is possible when the global is only used in one function, and that<br>
>> > function is known not to recurse (because if the function recurses, a<br>
>> > local<br>
>> > variable cannot be equivalent to a global as the global would hold state<br>
>> > over the recursive call).<br>
>> ><br>
>> > GlobalOpt has this ability already, however it is currently (a) weak and<br>
>> > (b)<br>
>> > broken.<br>
>> ><br>
>> > GlobalOpt has a special case for the function "main". It assumes that<br>
>> > any<br>
>> > function called "main" with external linkage is by definition<br>
>> > non-recursive.<br>
>> > It does this because in C++, main is defined by the standard not to<br>
>> > recurse.<br>
>> > However, this is not the case in C, so GlobalOpt will happily break C<br>
>> > code.<br>
>> ><br>
>> > GlobalOpt also currently won't even attempt to discover functions that<br>
>> > don't<br>
>> > recurse - it only checks "main".<br>
>> ><br>
>> > What I'd like to do is improve GlobalOpt to be more aggressive with<br>
>> > demoting<br>
>> > globals to locals, and to do that I need to teach it which functions are<br>
>> > known to be non-recursive. At the same time I'd really like to fix the<br>
>> > "main" kludge.<br>
>> ><br>
>> > There are three options I see:<br>
>> >   1. Just use an analysis pass to infer non-recursiveness as a property.<br>
>> > This can be a simple SCC pass which is queried by GlobalOpt.<br>
>> >   2. Add an attribute, "norecurse". This would be inferred just like<br>
>> > above<br>
>> > by FunctionAttrs in the general case, but it also allows frontends to<br>
>> > add<br>
>> > the attribute if they have specific knowledge - for example "main" in<br>
>> > C++<br>
>> > mode.<br>
>> >   3. (1), but use metadata to add the non-recursiveness information in<br>
>> > the<br>
>> > frontend, to solve the "main" problem.<br>
>> ><br>
>> > What I'm suggesting here is (2). I have no real problem implementing (3)<br>
>> > instead, and I think it's something that's worthwhile discussing. Adding<br>
>> > new<br>
>> > metadata is very cheap and easy and doesn't seem to have many downsides<br>
>> > as<br>
>> > an option.<br>
>> ><br>
>> > Hopefully I've described the problem and potential solutions well enough<br>
>> > -<br>
>> > what are peoples' thoughts? I quite like the attribute solution best,<br>
>> > but<br>
>> > I'd be happy with anything that moves us forward.<br>
>><br>
>> I think (2) is a good solution, but am wondering whether you intend to<br>
>> expose that attribute to users, or whether it's one that can only be<br>
>> created implicitly by the compiler?<br>
>><br>
>> ~Aaron<br>
>><br>
>> ><br>
>> > Cheers,<br>
>> ><br>
>> > James<br>
>> ><br>
>> > On Wed, 4 Nov 2015 at 17:46 Philip Reames via llvm-commits<br>
>> > <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
>> >><br>
>> >> This should probably be raised on llvm-dev for boarder visibility.<br>
>> >><br>
>> >> Side question: What optimizations or codegen opportunities does this<br>
>> >> enable?  i.e. what's the actual use case?<br>
>> >><br>
>> >><br>
>> >> On 11/02/2015 05:03 AM, James Molloy via llvm-commits wrote:<br>
>> >><br>
>> >> jmolloy created this revision.<br>
>> >> jmolloy added reviewers: manmanren, dexonsmith, joker.eph.<br>
>> >> jmolloy added a subscriber: llvm-commits.<br>
>> >> jmolloy set the repository for this revision to rL LLVM.<br>
>> >><br>
>> >> This attribute allows the compiler to assume that the function never<br>
>> >> recurses into itself, either directly or indirectly (transitively).<br>
>> >> This can<br>
>> >> be used among other things to demote global variables to locals.<br>
>> >><br>
>> >> The norecurse attribute indicates that the function does not call<br>
>> >> itself<br>
>> >> either directly or indirectly down any possible call path.<br>
>> >><br>
>> >> Repository:<br>
>> >>   rL LLVM<br>
>> >><br>
>> >> <a href="http://reviews.llvm.org/D14227" rel="noreferrer" target="_blank">http://reviews.llvm.org/D14227</a><br>
>> >><br>
>> >> Files:<br>
>> >>   docs/LangRef.rst<br>
>> >>   include/llvm/Bitcode/LLVMBitCodes.h<br>
>> >>   include/llvm/IR/Attributes.h<br>
>> >>   include/llvm/IR/Function.h<br>
>> >>   lib/AsmParser/LLLexer.cpp<br>
>> >>   lib/AsmParser/LLParser.cpp<br>
>> >>   lib/AsmParser/LLToken.h<br>
>> >>   lib/Bitcode/Reader/BitcodeReader.cpp<br>
>> >>   lib/Bitcode/Writer/BitcodeWriter.cpp<br>
>> >>   lib/IR/Attributes.cpp<br>
>> >>   lib/IR/Verifier.cpp<br>
>> >>   test/Bindings/llvm-c/invalid-bitcode.test<br>
>> >>   test/Bitcode/attributes.ll<br>
>> >>   test/Bitcode/compatibility.ll<br>
>> >>   test/Bitcode/invalid.ll<br>
>> >>   test/LTO/X86/invalid.ll<br>
>> >><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> llvm-commits mailing list<br>
>> >> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
>> >><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> llvm-commits mailing list<br>
>> >> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> ><br>
</blockquote></div>