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