[llvm-dev] [PATCH] D14227: Add a new attribute: norecurse

Thu Nov 5 08:31:45 PST 2015

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
>> >> >