[PATCH] Add support for optimization reports.

Diego Novillo dnovillo at google.com
Thu Apr 3 10:32:39 PDT 2014


On Wed, Apr 2, 2014 at 10:03 PM, Diego Novillo <dnovillo at google.com> wrote:
> 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 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.



More information about the cfe-commits mailing list