[PATCH] D29023: [Stack Protection] Add diagnostic information for why stack protection was applied to a function

[Adam Nemet via Phabricator via llvm-commits]

anemet added a comment.

In https://reviews.llvm.org/D29023#683484, @jhenderson wrote:

> After staring at this for a while, and discussing terminology, I have come to the conclusion that the best way to report these remarks is not via a new diagnostic class, but rather through simply using emitOptimizationRemark. This updated diff simplifies things substantially from the previous version and also gives us clang support for free via -Rpass=stack-protector.


I was going to propose the same thing but I am pretty biased toward opt-remarks so I decided against it.  I am glad you came to the same conclusion independently ;).

One thing that you should use is the OptimizationRemarkEmitter facility instead of using the C API.  This allows exporting opt remarks into a YAML file with -fsave-optimization-record.  Then you can visualize with opt-viewer like this:

https://androm3da.github.io/optviewer-demo/output_analysis/cpython/._Modules_hashtable.c.html#L493

Looks like LoopInfo/DomintorTree is not available in SSP so it's probably more efficient for now to instantiate ORE on the fly rather than using it as analysis pass.  Once something like https://reviews.llvm.org/D30128 is implemented for IR-level ORE, I can come back to this and make it use the analysis pass.  The same approach is used by the loop passes currently, see LegacyLICMPass::runOnLoop for an example.


https://reviews.llvm.org/D29023