[NFC][FuncAttrs] Add comment on why we look for noreturn calls

[aeubanks]

Summary

Followup to https://reviews.llvm.org/D93946.

[reames]

I'm dropping my request which triggered this review. Feel free to close.

Why? Because I went and looked into this further, and neither the old nor new pass manager actually handle this in a sane way. With the recent changes, they both handle it in approximately the same insane way.

Both have a nice bottom up traversal of the call graph. You think we'd simplify the SCC, then infer properties, than move to the caller SCC and exploit them right? Well, no. We infer, then simplify, then go to the caller. The result is that we don't get to benefit from any of the simplification when doing the analysis.

llvm/lib/Transforms/IPO/FunctionAttrs.cpp

if (auto *CB = dyn_cast<CallBase>(&I)) {
     Function *Callee = CB->getCalledFunction();
     return Callee && Callee->doesNotReturn();
   }
   return false;
 }
 
 // A basic block can only return if it terminates with a ReturnInst and does not
 // contain calls to noreturn functions.
+// If we could assume that something like SimplifyCFG would always run before
+// FunctionAttrs and replace code after instructions that don't return with
+// unreachable, we would only need to look at the terminator. However, that's
+// not always true; for example the new PM's CGSCC pipeline first runs
+// FunctionAttrs, then function simplification passes.
 static bool basicBlockCanReturn(BasicBlock &BB) {
   if (!isa<ReturnInst>(BB.getTerminator()))
     return false;
   return none_of(BB, instructionDoesNotReturn);
 }
 
 // Set the noreturn function attribute if possible.
 static bool addNoReturnAttrs(const SCCNodeSet &SCCNodes) {