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

[James Molloy via llvm-dev]

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

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 listllvm-commits at lists.llvm.orghttp://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151105/28561cd5/attachment.html>