[LLVMdev] RFC - Adding an optimization report facility?

[Diego Novillo]

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?


>
> 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.

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?


Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140307/f2e6aecb/attachment.html>