[PATCH] D29023: [Stack Protection] Add diagnostic information for why stack protection was applied to a function
Adam Nemet via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 22 11:08:12 PST 2017
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
More information about the llvm-commits
mailing list