If a function doesn't contain loops and does not call non-willreturn functions, then it is willreturn. Handling of the loop case is left as an exercise to the reader ;)
I think this should give us enough inference to move forward with D94106.
Differential D94633
[FunctionAttrs] Infer willreturn for functions without loops nikic on Jan 13 2021, 1:48 PM. Authored by
Details If a function doesn't contain loops and does not call non-willreturn functions, then it is willreturn. Handling of the loop case is left as an exercise to the reader ;) I think this should give us enough inference to move forward with D94106.
Diff Detail Event TimelineComment Actions I still think we should check to enable a light-attributor run in the beginning of the pipeline. The logic seems sound, could be improved since this does initialize the fixpoint computation with a pessimistic starting value. One comment below, the rest is OK for merging.
Comment Actions I was hoping to get the willreturn-related bugs fixed in time for LLVM 12, so sticking to the existing infrastructure seems like the safer bet :) It probably makes more sense to enable the attributor after branching rather than before.
I thought about this, but I don't think that we can use an optimistic fixpoint here without some much more sophisticated analysis. Just naively assuming "willreturn until proven otherwise" will incorrectly mark infinite recursion as willreturn: ; Not willreturn. define void @willreturn_recursion() { tail call void @willreturn_recursion() ret void } Without mustprogress, I believe that function is well-defined (or at least with musttail it's well-defined for sure). Inferring willreturn for a non-trivial SCC (without mustprogress) would require proving that the recursion is finite. And as the current code doesn't even handle finite loops, this is a bit out of scope...
Comment Actions EDIT: I'm fine with this patch, FWIW. Fair. As I said, we can enable it in a restricted, lightweight mode first. Could you remind me which bugs?
So, I run this through the Attributor: https://opt.godbolt.org/z/TqsK86
I don't disagree. My concern is that we should add more sophisitcated the logic in the Attributor instead. We had some initial patches wrt. finite loops, but I don't think they went in. Comment Actions D94106 fixes the important one, though isGuaranteedToTransferExecutionToSuccessor is also buggy for languages without forward progress. Functions with infinite loops getting optimized away is the number one Rust miscompile by quite a margin...
Just to make sure we're on the same page, both of those would be bugs in attributor right? The first one shouldn't be unreachable, and the second one shouldn't be willreturn, at least not without more information than is contained in that IR.
Comment Actions Right. We should not delete non-mustprogress non-side-effect calls. Probably requires changes in a few more places.
I agree for the first one. Mustprogress is missing for unreachable to correct. The second one is correct, or am I missing something?
|
We do not really need to find all back edges, wouldn't it be sufficient to just traverse the CFG and exit once we found a cycle?