[PATCH] Add support for optimization reports.

Diego Novillo dnovillo at google.com
Wed Apr 2 19:03:05 PDT 2014


On Mon, Mar 31, 2014 at 8:05 PM, Quentin Colombet <qcolombet at apple.com> wrote:

> ================
> Comment at: lib/CodeGen/CodeGenAction.cpp:419
> @@ -394,1 +418,3 @@
> +      OptimizationReportHandler(cast<DiagnosticInfoOptimizationReport>(DI));
> +    return;
>    default:
> ----------------
> This does not follow the same pattern as the previous handler, i.e., with the fall through setting the DiagID to use the default handler (the ComputeDiagID part etc.).
>
> My guess is we want to push the check of CodeGenOpts.OptimizationReportPattern into OptimizationReportHandler and check the return of that.
>
> If we do not want to follow the same pattern, we should comment on that. Indeed, I think it is important to explain why we are not reporting anything when CodeGenOpts.OptimizationReportPattern is not set.

I've been thinking about this a bit, and I'm not completely sure how
to handle it.  My initial idea with these optimization remarks is to
allow clients to emit them unconditionally, and allow the diagnostic
machinery check whether the report should be generated.

In the inliner, you'll see that to generate a remark, it calls the
diagnostic directly. If there is a regexp pattern given and it matches
the word 'inline', then it gets emitted.

The downside of this is that when the front end is not involved (say,
when using opt) the remark is always emitted. So, I think I'm not
going to be able to do this unconditionally. However, I would like to
avoid adding a cl::opt flag to every pass we want to add optimization
remarks to.

Another thing that I'm doing is using the pass's DEBUG_NAME as the
optimization name. I suppose that's OK, but it may not be. I'm open to
any suggestions on how to expose this to 'opt'.


I've modified the two patches to incorporate all your and Richard's suggestions.


Thanks.  Diego.



More information about the cfe-commits mailing list