Deduce the "willreturn" attribute for functions.
For now, intrinsics are not willreturn. More annotation will be done in another patch.
Differential D63046
[Attributor] Deduce "willreturn" function attribute uenoku on Jun 8 2019, 7:18 AM. Authored by
Details Deduce the "willreturn" attribute for functions. For now, intrinsics are not willreturn. More annotation will be done in another patch.
Diff Detail
Event TimelineComment Actions The current algorithm can deduce only for very simple cases.
I'll work on allowing some loops next. Comment Actions Can you clang format the code? What about the test changes?
Comment Actions
I always clang format before submitting a patch. Comment Actions I forgot why I thought it was not formatted. Forget that comment. Last comments wrt class placement.
Comment Actions Declare isKnownWillReturn and isAssumedWillReturn in the base class. Then place the base class in the header. Otherwise, LGTM. (Can you also make the dependences explicit so I know when I can commit these things, use the edit related revisions button). Comment Actions
What about functions that exit the program, throw an exception, or longjmp?
Comment Actions I know I just posted, but I think I figured out the right rule. The rule you want is a) doesn't have a cycle b) all calls have willreturn. A function with no calls (and no cycles) can have willreturn, and a function that calls only willreturn functions (and no cycles) can have willreturn. That's assuming you don't mind a function being both willreturn and noreturn at the same time (a function that ends in unreachable). I think we just accept that, there's no point trying to prove any code free from undefined behaviour. If I'm right, this patch doesn't need to depend on norecurse. Comment Actions That was an oversight in the comment but not the code, I think. There are tests for calls and exceptions. The former may prevent willreturn the latter doesn't (as of D62801). This way, willreturn is orthogonal to nothrow.
Strictly speaking, it doesn't. But for now, that makes it much simpler. If you only make sure calls are optimistically willreturn you get willreturn for a potential endless recursion. That is, a function that might, depending on the input, recurse forever or not. Now, norecurse is actually "too strong" but that is fine for now.
Comment Actions
I'll fix it to check noreturn.
Comment Actions
Comment Actions @nicholas If you want to discuss any of this further, please say so.
Comment Actions @jdoerfert Comment Actions Take the AANoRecurse abstract attribute interface (no implementation) and add it to this patch. That will not improve the results but will make it work once we derive it. Comment Actions For some intrinsics, I can not judge whether it is allowed to mark willreturn. I want to hear an opinion.
Comment Actions Can we do the following:
Basically, split the patch in two and commit the first part assuming the comments in (https://reviews.llvm.org/D63046#1572140) have been addressed. To answer your question: memcpy, memmove, memset are willreturn Comment Actions OK, I'll split a patch for mem*or other stuff.
|
In line with isGuaranteedToTransferExecutionToSuccessor(), isn't it also necessary to check for volatile memory operations, which may trap?