Add 'remark' diagnostic type in LLVM

[Tobias Grosser]

On 02/25/2014 11:48 AM, Alp Toker wrote:
>
> On 25/02/2014 10:18, Tobias Grosser wrote:
>> Hi,
>>
>> I would like to add the following patch.
>>
>> --------------
>> Add 'remark' diagnostic type in LLVM
>>
>> A 'remark' is information that is not an error or a warning, but
>> rather some additional information provided to the user. In contrast
>> to a 'note' a 'remark' is an independent diagnostic, whereas a 'note'
>> always depends on another diagnostic.
>>
>> A typical use case for remark nodes is information provided to the
>> user, e.g. information provided by the vectorizer about loops that
>> have been vectorized.
>
>
> One nice thing about warnings is that they can be suppressed with -Wno
> or upgraded to errors with -Werror= and effort has been made to ensure
> each warning has an associated option (mostly useful for built-in
> diagnostics).
>
> I'm guessing this remark capability is intended to support Quentin's
> backend diagnostics -- could you provide some background on the planned
> mechanism to enable or suppress them?

Hi Alp,

yes, this is intended for Quentin's backend diagnostics and the question 
you ask is very valid.

The current diagnostics emitted in the backend are all warnings or 
errors and are controlled by explicit flags (-Wbackend-plugin, 
-Winline-asm,..). This is already taken care of.

For the 'remark' diagnostics I just proposed I did not yet add any 
flags. I also do not think it makes sense to use -Werror or something to 
promote those remarks to errors.

However, enabling them using command line options is necessary. I see 
two approaches here:

1) Model them similar to the -W flags

We could use something like '-Rvector '-Rno-vector' to enable these 
diagnostics. And then allow more fine-grained control with 
'-Rloop-vector' or '-Rslp-vector'.

-R does not yet have any meaning for clang and gcc, so using it for this 
purpose may be fine. This may also give us another data-point for the 
'info' vs. 'remark' discussion currently going on as "-I" is already taken.

To later enable different verbosity modes, we could use a formulation 
such as '-Rvector=3' with '-Rno-vector' equal to '-Rvector=0'.

2) Have separate flags

We could control those also with flags such as -vec-report=3 (icc) or
-ftree-vectorizer-verbose=n (gcc)

This is less systematic but possibly more straightforward. And as those 
'remarks' are off by default we may not really need a systematic way to 
identify the flags needed to turn off the diagnostics.

Do we have any preferences here?

Cheers,
Tobias