[LLVMdev] RFC - Adding an optimization report facility?

[Tobias Grosser]

On 03/07/2014 02:57 PM, Diego Novillo wrote:
> On Thu, Mar 6, 2014 at 6:43 PM, Tobias Grosser <tobias at grosser.es> wrote:
>
>>
>>   In this context, I only want
>>> to enable all remarks.
>>>
>>
>> I can see that. How to do this is really open for discussion. I could see
>> us establishing two new flags '-Wall-remarks' for remarks and
>> '-Wall-warnings' for warnings. Or, what I prefer, we could establish a new
>> flag hierarchy e.g. with '-Reverything'.
>>
>
> I quite like the notion of a new flag hierarchy.  Using -W seems like
> semantic overload.  -W already implies diagnostics about dubious constructs
> in the code. These notices are pure reporting on optimization activities.
>
>
> 5. Enable/Disable remarks with pragmas / per function
>>
>> Yes, there are a lot of things to do here. The diagnostic infrastructure
>> already provides great features, e.g.:
>>
>>    - Enabling/Disabling diagnostics with pragmas and per function
>>    - Nested diagnostic groups
>>    - Enabling a diagnostic group, but disabling individual diagnostics
>>      or this group.
>>    - Good integration in tools through libclang
>>    - ...
>>
>> However, the command line interface might need to be improved before we
>> start adding a large number of remarks. Some goals I see:
>>
>> 1) We want to reuse as much of the diagnostic infrastructure as possible
>> 2) We do not want to increase the complexity of the warning flags too much
>> 3) We still want to have a similar user interface as the warning flags
>> provide
>> 4) People raised interest in upgrading remarks to warnings or errors
>>     (I am personally not too sure about this one, but it already works
>>      with -Werror=groupname)
>>
>
> Yes to all.  Not so sure about #4.  Convert the reports into errors?  As
> in, fail the build if an inline didn't happen?

Yes, some people requested/suggested this, as it might make sense for 
certain remarks and as e.g. the edg frontend has a generic diagnostic 
system where all diagnostics can be upgraded/downgraded by will.
Though, as said above, I am not fully convinced yet. I would not make it 
a priority now.

>> Several people (including Chris) warned to build up an additional complex
>> diagnostic system on the side, but as Chandler pointed out, we can most
>> likely reuse most of the existing infrastructure but could still adjust the
>> user interface if needed.
>>
>
> Yes, the one additional ability we'll likely want is to direct these
> reports to files. Though that could be added later.
>
>
>>
>> I personally believe the best approach is to start small and let the
>> design be driven by the intended use cases. If you are interested, I would
>> propose to add a single diagnostic for the loop inliner using just the
>> existing '-W' infrastructure e.g. with '-Winline-remarkers'.
>>
>
> Agreed. I prefer an evolutionary approach.

Cool. If you need anyone to review patches, I am very interested to do so.

> This both increases test coverage of the exiting features and also
>> will help to get an idea of the needed features. At the same time, you
>> could help reviewing my first patch on modularizing the clang diagnostic
>> infrastructure. Again, something that may help to get an idea of where to
>> head at this side.
>>
>
> Sure. You mean r202475?

My patch is currently unreviewed on clang-commits. It's an email with 
the title '[PATCH] tblgen: Modularize the diagnostic emitter'.

Cheers,
Tobias