On Wed, Apr 2, 2014 at 10:03 PM, Diego Novillo <[email protected]> wrote: > 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 been thinking about the following approach. Add a -pass-remarks=regexp to 'opt'. When the driver sees -Rpass=regexp, it adds -pass-remarks=regexp to the backend command line. I then implement some supporting code similar to lib/Support/Debug.cpp. Passes call this support routine, which in turn will generate a real diagnostic only if the regexp matches the given pass name. This way, the low-level diagnostic handlers can use the same structure as the others and we get a way of specifying optimization reports from the driver and opt. How does that sound? Diego. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
