This is an archive of the discontinued LLVM Phabricator instance.

[FunctionAttrs] Calls to libcalls don't cause a function to potentially recurse
AbandonedPublic

Authored by jmolloy on Nov 18 2015, 3:51 AM.

Details

Summary

If a function calls a library function, that shouldn't be treated as potentially causing a cycle in the CFG. Additionally calls to noreturn functions are norecurse by definition.

Diff Detail

Repository
rL LLVM

Event Timeline

jmolloy updated this revision to Diff 40490.Nov 18 2015, 3:51 AM
jmolloy retitled this revision from to [FunctionAttrs] Calls to libcalls don't cause a function to potentially recurse.
jmolloy updated this object.
jmolloy set the repository for this revision to rL LLVM.
jmolloy added a subscriber: llvm-commits.
dexonsmith edited edge metadata.Nov 18 2015, 4:53 AM
dexonsmith added a subscriber: dexonsmith.

Calls to exit() can recurse because of atexit() handlers. The same might be true of other libcalls?

Also, other noreturn functions can recurse; it's a weird path but I don't think it's malformed:

void bar() noreturn;
int foo() {
static bool Return = false;
if (Return) return 5;
Return = true;
bar();
}

void bar() {
sink(foo());
exit();

}

jmolloy abandoned this revision.Nov 18 2015, 5:00 AM

Hi Duncan,

Damn, you're right. I didn't even consider atexit handlers. And that noreturn case is true too. I'll abandon this.

Cheers,

James

Yeah, this would have been nice :(. There might be something you can do for certain LLVM intrinsics?

mehdi_amini edited edge metadata.Nov 18 2015, 11:03 AM

Like... modifying there tablegen definition to add the norecurse attribute?