<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Tobias,<div><br><div><div>On Feb 25, 2014, at 4:19 AM, Tobias Grosser <<a href="mailto:tobias@grosser.es">tobias@grosser.es</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 02/25/2014 11:48 AM, Alp Toker wrote:<br><blockquote type="cite"><br>On 25/02/2014 10:18, Tobias Grosser wrote:<br><blockquote type="cite">Hi,<br><br>I would like to add the following patch.<br><br>--------------<br>Add 'remark' diagnostic type in LLVM<br><br>A 'remark' is information that is not an error or a warning, but<br>rather some additional information provided to the user. In contrast<br>to a 'note' a 'remark' is an independent diagnostic, whereas a 'note'<br>always depends on another diagnostic.<br><br>A typical use case for remark nodes is information provided to the<br>user, e.g. information provided by the vectorizer about loops that<br>have been vectorized.<br></blockquote><br><br>One nice thing about warnings is that they can be suppressed with -Wno<br>or upgraded to errors with -Werror= and effort has been made to ensure<br>each warning has an associated option (mostly useful for built-in<br>diagnostics).<br><br>I'm guessing this remark capability is intended to support Quentin's<br>backend diagnostics -- could you provide some background on the planned<br>mechanism to enable or suppress them?<br></blockquote><br>Hi Alp,<br><br>yes, this is intended for Quentin's backend diagnostics and the question you ask is very valid.<br><br>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.<br><br>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.<br></div></blockquote>Agreed.</div><div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>However, enabling them using command line options is necessary. I see two approaches here:<br><br>1) Model them similar to the -W flags<br><br>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'.<br><br>-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.<br><br>To later enable different verbosity modes, we could use a formulation such as '-Rvector=3' with '-Rno-vector' equal to '-Rvector=0’.<br></div></blockquote><div>I have a preference for this approach. This will be easier to present the information in a consistent way to the user.</div><div>On the other hand, we may want to be compatible with gcc flags. But I guess we can produce some aliases if this is a requirement.</div><div><br></div><div>Regarding the patch itself.</div><div>Assuming we pursue in that direction, this is breaking the API compatibility:</div><div><div>   LTO_DS_WARNING,</div><div>+  LTO_DS_REMARK,</div><div>   LTO_DS_NOTE</div><div> } lto_codegen_diagnostic_severity_t;</div><div><br></div><div>More sure to bump the LTO API version with that change.</div><div><br></div><div>Thanks,</div><div>-Quentin</div></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>2) Have separate flags<br><br>We could control those also with flags such as -vec-report=3 (icc) or<br>-ftree-vectorizer-verbose=n (gcc)<br><br>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.<br><br>Do we have any preferences here?<br><br>Cheers,<br>Tobias</div></blockquote></div><br></div></body></html>