This is an archive of the discontinued LLVM Phabricator instance.

Add a new attribute: norecurse
ClosedPublic

Authored by jmolloy on Nov 2 2015, 5:03 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

jmolloy updated this revision to Diff 38892.Nov 2 2015, 5:03 AM
jmolloy retitled this revision from to Add a new attribute: norecurse.
jmolloy updated this object.
jmolloy set the repository for this revision to rL LLVM.
jmolloy added a subscriber: llvm-commits.
jmolloy added inline comments.
test/Bindings/llvm-c/invalid-bitcode.test
3

These invalid bitcode tests were checking an attribute that is now valid.

I've updated the binary bitcode file to use attribute "50" instead - but obviously phab can't show that.

mehdi_amini edited edge metadata.Nov 2 2015, 11:15 AM

Patch looks good to me, but it would be nice to have more support for the attribute (or maybe at least wait a little bit for people to be able to object).

include/llvm/IR/Function.h
328

Just a nitpick: I believe we enabled autobrief and we shouldn't add it anymore when unnecessary.

Why an attribute specifying that recursion does not happen instead of one
specifying that it does? It seems like functions generally do not recurse,
which suggests marking recursion would require less annotations.

~Aaron

James,

Have you considered what happens with something along the lines of:

void f() {
  g();
}
void g() {
  g();
}

In this case, we can clearly see that f doesn't recurse onto itself but g does.

I am concerned that if we infer norecurse, we will hit cases where transformations along the lines of inlining invalidate the attribute.

The fact that a transformation may invalidate the attribute seems to me to be independent from wether we infer it or not: the same example you took could come from a specific front-end (or directly a user) adding the attributes. I think we'll have to teach such a transformation that invalidate the attribute to either not perform when the attribute is present, or remove it. Does it makes sense?
Do you foresee a lot of such transformations? Or cases where it would be hard to do?

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?

jmolloy marked an inline comment as done.Nov 6 2015, 2:35 AM

I committed this in r252282, with the autobrief change as suggested by Mehdi.

hfinkel accepted this revision.Dec 10 2015, 4:49 PM
hfinkel added a reviewer: hfinkel.
hfinkel added a subscriber: hfinkel.

(will close)

This revision is now accepted and ready to land.Dec 10 2015, 4:49 PM
hfinkel closed this revision.Dec 10 2015, 4:49 PM

This was committed as r252282