On Mon, Mar 31, 2014 at 8:05 PM, Quentin Colombet <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
