James Molloy via llvm-dev
2015-Nov-05 16:26 UTC
[llvm-dev] [PATCH] D14227: Add a new attribute: norecurse
Ah I see. 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? James On Thu, 5 Nov 2015 at 16:08 Aaron Ballman <aaron at aaronballman.com> wrote:> On Thu, Nov 5, 2015 at 11:06 AM, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Aaron, > > > > I think it must necessarily be exposed to users - clang must add it in > > certain circumstances for example. I don't think this is particularly > > different to many other attributes such as nocapture/nounwind, that are > > exposed to users and can be set by users in exceptional circumstances but > > are primarily inferred by the midend. > > Sorry, I was unclear. I meant to Clang users as a language-level > attribute (e.g., [[clang::norecurse]]), not LLVM users as an IR-level > attribute. > > ~Aaron > > > > > > James > > > > On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <aaron at aaronballman.com> > wrote: > >> > >> On Thu, Nov 5, 2015 at 10:44 AM, James Molloy via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >> > [Adding llvm-dev and re-stating the situation for llvm-dev's benefit] > >> > > >> > RFC: A new attribute, "norecurse". > >> > > >> > 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). > >> > > >> > GlobalOpt has this ability already, however it is currently (a) weak > and > >> > (b) > >> > broken. > >> > > >> > 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. > >> > > >> > GlobalOpt also currently won't even attempt to discover functions that > >> > don't > >> > recurse - it only checks "main". > >> > > >> > 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. > >> > > >> > There are three options I see: > >> > 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. > >> > 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. > >> > 3. (1), but use metadata to add the non-recursiveness information in > >> > the > >> > frontend, to solve the "main" problem. > >> > > >> > 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. > >> > > >> > 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. > >> > >> I think (2) is a good solution, but am wondering whether you intend to > >> expose that attribute to users, or whether it's one that can only be > >> created implicitly by the compiler? > >> > >> ~Aaron > >> > >> > > >> > Cheers, > >> > > >> > James > >> > > >> > On Wed, 4 Nov 2015 at 17:46 Philip Reames via llvm-commits > >> > <llvm-commits at lists.llvm.org> wrote: > >> >> > >> >> This should probably be raised on llvm-dev for boarder visibility. > >> >> > >> >> Side question: What optimizations or codegen opportunities does this > >> >> enable? i.e. what's the actual use case? > >> >> > >> >> > >> >> On 11/02/2015 05:03 AM, James Molloy via llvm-commits wrote: > >> >> > >> >> 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 > >> >> > >> >> http://reviews.llvm.org/D14227 > >> >> > >> >> 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 > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> llvm-commits mailing list > >> >> llvm-commits at lists.llvm.org > >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits > >> >> > >> >> > >> >> _______________________________________________ > >> >> llvm-commits mailing list > >> >> llvm-commits at lists.llvm.org > >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits > >> > > >> > > >> > _______________________________________________ > >> > LLVM Developers mailing list > >> > llvm-dev at lists.llvm.org > >> > http://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/20151105/35bc155c/attachment.html>
Aaron Ballman via llvm-dev
2015-Nov-05 16:31 UTC
[llvm-dev] [PATCH] D14227: Add a new attribute: norecurse
On Thu, Nov 5, 2015 at 11:26 AM, James Molloy <james at jamesmolloy.co.uk> wrote:> Ah I see. > > 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?I would prefer to avoid it, actually. :-D ~Aaron> > James > > On Thu, 5 Nov 2015 at 16:08 Aaron Ballman <aaron at aaronballman.com> wrote: >> >> On Thu, Nov 5, 2015 at 11:06 AM, James Molloy <james at jamesmolloy.co.uk> >> wrote: >> > Hi Aaron, >> > >> > I think it must necessarily be exposed to users - clang must add it in >> > certain circumstances for example. I don't think this is particularly >> > different to many other attributes such as nocapture/nounwind, that are >> > exposed to users and can be set by users in exceptional circumstances >> > but >> > are primarily inferred by the midend. >> >> Sorry, I was unclear. I meant to Clang users as a language-level >> attribute (e.g., [[clang::norecurse]]), not LLVM users as an IR-level >> attribute. >> >> ~Aaron >> >> >> > >> > James >> > >> > On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <aaron at aaronballman.com> >> > wrote: >> >> >> >> On Thu, Nov 5, 2015 at 10:44 AM, James Molloy via llvm-dev >> >> <llvm-dev at lists.llvm.org> wrote: >> >> > [Adding llvm-dev and re-stating the situation for llvm-dev's benefit] >> >> > >> >> > RFC: A new attribute, "norecurse". >> >> > >> >> > 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). >> >> > >> >> > GlobalOpt has this ability already, however it is currently (a) weak >> >> > and >> >> > (b) >> >> > broken. >> >> > >> >> > 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. >> >> > >> >> > GlobalOpt also currently won't even attempt to discover functions >> >> > that >> >> > don't >> >> > recurse - it only checks "main". >> >> > >> >> > 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. >> >> > >> >> > There are three options I see: >> >> > 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. >> >> > 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. >> >> > 3. (1), but use metadata to add the non-recursiveness information >> >> > in >> >> > the >> >> > frontend, to solve the "main" problem. >> >> > >> >> > 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. >> >> > >> >> > 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. >> >> >> >> I think (2) is a good solution, but am wondering whether you intend to >> >> expose that attribute to users, or whether it's one that can only be >> >> created implicitly by the compiler? >> >> >> >> ~Aaron >> >> >> >> > >> >> > Cheers, >> >> > >> >> > James >> >> > >> >> > On Wed, 4 Nov 2015 at 17:46 Philip Reames via llvm-commits >> >> > <llvm-commits at lists.llvm.org> wrote: >> >> >> >> >> >> This should probably be raised on llvm-dev for boarder visibility. >> >> >> >> >> >> Side question: What optimizations or codegen opportunities does this >> >> >> enable? i.e. what's the actual use case? >> >> >> >> >> >> >> >> >> On 11/02/2015 05:03 AM, James Molloy via llvm-commits wrote: >> >> >> >> >> >> 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 >> >> >> >> >> >> http://reviews.llvm.org/D14227 >> >> >> >> >> >> 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 >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> llvm-commits mailing list >> >> >> llvm-commits at lists.llvm.org >> >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> llvm-commits mailing list >> >> >> llvm-commits at lists.llvm.org >> >> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >> >> > >> >> > >> >> > _______________________________________________ >> >> > LLVM Developers mailing list >> >> > llvm-dev at lists.llvm.org >> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >
Duncan P. N. Exon Smith via llvm-dev
2015-Nov-05 17:45 UTC
[llvm-dev] [PATCH] D14227: Add a new attribute: norecurse
> On 2015-Nov-05, at 08:31, Aaron Ballman <aaron at aaronballman.com> wrote: > > On Thu, Nov 5, 2015 at 11:26 AM, James Molloy <james at jamesmolloy.co.uk> wrote: >> Ah I see. >> >> 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? > > I would prefer to avoid it, actually. :-DI agree we should avoid exposing this as a clang attribute (at least to start); I imagine it would be easy to misuse.