r213112 - Handle diagnostic warnings in Frontend diagnostic handler.

[Tyler Nowicki]

Hi Alp,

Thanks for the review. I incorporated some of your suggestions. Please review the patches below.


>>      void
>>      OptimizationRemarkHandler(const llvm::DiagnosticInfoOptimizationRemark &D);
>>      void OptimizationRemarkHandler(
>>          const llvm::DiagnosticInfoOptimizationRemarkMissed &D);
>>      void OptimizationRemarkHandler(
>>          const llvm::DiagnosticInfoOptimizationRemarkAnalysis &D);
>> +    void OptimizationWarningHandler(
>> +        const llvm::DiagnosticInfoOptimizationWarning &D);
> 
> I don't get this. The frontend maps backend remarks to frontend diagnostics so why the special case?

This is patch is not another remark. See LLVM commit r213110 which added the warnings to llvm. We produce a warning when an explicitly specified optimization (currently vectorization or interleaving) fails. In clang the user can explicitly specify vectorization, interleaving, and unrolling with a pragma clang loop directive.


>>  -  Diags.Report(Loc, DiagID) << AddFlagValue(D.getPassName())
>> -                            << D.getMsg().str();
>> +  // Flag value not used by all optimization messages.
>> +  if (D.getPassName())
>> +    Diags.Report(Loc, DiagID) << AddFlagValue(D.getPassName())
>> +                              << D.getMsg().str();
>> +  else
>> +    Diags.Report(Loc, DiagID) << D.getMsg().str();
> 
> Is this change necessary? The existing code had the same functionality without the need for an if/else here AFAICT.

If I changed the implementation of AddFlagValue it might work. The problem is that it is a struct and its constructor expects a StringRef. This is constructed implicitly from the char* returned by getPassName(). But this could be null causing an assertion when building the StringRef.


> I think the plan was to handle this with user-defined diagnostic mappings rather than what's being done here.

What do you mean? Can you elaborate?

Tyler

LLVM:



Clang:


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140717/315fd09a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm_vectorization_failure-svn.patch
Type: application/octet-stream
Size: 2878 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140717/315fd09a/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140717/315fd09a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang_pragma_failure-svn.patch
Type: application/octet-stream
Size: 6466 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140717/315fd09a/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140717/315fd09a/attachment-0002.html>