This is an archive of the discontinued LLVM Phabricator instance.

[remark][diagnostics] Using clang diagnostic handler for IR input files
ClosedPublic

Authored by xur on Jan 10 2020, 10:16 AM.

Details

Summary

For IR input files, we currently use LLVM diagnostic handler even the
compilation is from clang. As a result, we are not able to use -Rpass
to get the transformation reports. Some warnings are not handled
properly either: We found many mysterious warnings in our ThinLTO backend
compilations in SamplePGO and CSPGO. An example of the warning:

warning: net/proto2/public/metadata_lite.h:51:21: 0.02% (1 / 4999)

This turns out to be a warning by Wmisexpect, which is supposed to be
filtered out by default. But since the filter is in clang's
diagnostic hander, we emit these incomplete warnings from LLVM's
diagnostic handler.

This patch uses clang diagnostic handler for IR input files. We create
a fake backendconsumer just to install the diagnostic handler.
The location information is tightly coupled with the sourcemanager which
is not available in IR input files. I just prepend the location from DebugLoc
to the warning/remark messages. I think this is much simpler way than
to pass DebugLoc to DiagnosticEngine (I tried this approach, but it seemed to
require much more extensive changes).

With this change, we will have proper handling of all the warnings and we can
use -Rpass* options in IR input files compilation.
Also note that with is patch, LLVM's diagnostic options, like
"-mllvm -pass-remarks=*", are no longer be able to get optimization remarks.

Diff Detail

Event Timeline

xur created this revision.Jan 10 2020, 10:16 AM
ychen added a subscriber: ychen.Jan 10 2020, 10:25 AM

Thanks for fixing this missing -Rpass support!

clang/lib/CodeGen/CodeGenAction.cpp
594

Does this only happen with IR input? Does it always happen with IR input? If not, what happens when we have a non-null Context but IR input? It sounds like it should still always return an invalid Loc since there is no SourceManager? In that case can you set a flag on the BackendConsumer so we can bail out directly in the IR input case, instead of going through the motions only to get an invalid Loc back anyway? It would also be more clear.

645

Can you add a test for this one?

Also, what determines the format of the message when Loc is valid? I was trying to figure out where that got determined, but couldn't easily track it down.

clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
9

In this case (since no -Wmisexpect), presumably we should not be getting the warning, whereas without your fix we were, correct? In that case, please add a NOT check to confirm that we don't get the message anymore.

xur marked 3 inline comments as done.Jan 13 2020, 9:18 AM
xur added inline comments.
clang/lib/CodeGen/CodeGenAction.cpp
594

Before this patch, IR input does not called to this function. IR input has a null Context (so it will seg-fault at the dereference at line 598). Context == nullptr should be only happening with the empty BackendConsume that installed in this patch.
I tried to set Context but the whole point was to get SrouceManager which was not available for IR input.

645

Do you mean adding a test to test the path of branch starting line 650?
(For the case of valid Loc, I don't think we need to test as it's not changed.)

If so, there is already a test for this:
clang/test/CodeGen/backend-unsupported-error.ll
I think this calls to llvm's diagnostic handler for IR input files (before this patch). The format is here:
DiagnosticInfoUnsupported::print(...) in llvm/lib/IR/DiagnosticInfo.cpp

For the case of input other than IR files, the Diags should go to clang diagnostic handler. This patch might change the behavior.

I think I will check Context == nullptr directly (rather Loc.isValid). This way we don't need to call into getBestLocationFromDebugLoc(), and it will not affect non-IR input files.

clang/test/CodeGen/thinlto-clang-diagnostic-handler-in-be.c
9

Yes. You are right.
I will add a NOT check to confirm this.

xur updated this revision to Diff 237716.Jan 13 2020, 9:52 AM

Integrated Teresa's review comments.

tejohnson added inline comments.Jan 13 2020, 12:12 PM
clang/lib/CodeGen/CodeGenAction.cpp
594

Since Context==nullptr iff IR input, then for clarity can you add a comment by these checks that this case is specifically corresponding to when we have IR input?

(Also, I was a little confused when I first reviewed this since I didn't realize this Context variable was an ASTContext and not the LLVMContext being passed in to the new BackendConsumer constructor, now I see why it is always null in that case.)

645

Do you mean adding a test to test the path of branch starting line 650?

Yes, but:

If so, there is already a test for this:
clang/test/CodeGen/backend-unsupported-error.ll

I see, I didn't realize this was already being tested with IR input. Nevermind then.

The format is here:
DiagnosticInfoUnsupported::print(...) in llvm/lib/IR/DiagnosticInfo.cpp

Ok thanks. Looking at that file, I'm wondering if we can use those facilities directly rather than cloning the formatting code here. I.e. instead of constructing a MsgStream manually here, duplicating the code in DiagnosticInfoUnsupported::print, couldn't this handling be something like:

DiagnosticPrinterRawOStream DP(MsgStream);
D.print(DP);

These lines would subsume the manual setup of MsgStream in the null Context case, as well as the MsgStream << D.getMessage() line below it. Then you would still call Diags.Report with MsgStream.str() as usual.

And ditto for the other 2 types of DiagnosticInfos below. This mechanism is used in quite a few diagnostic handlers setup in LLVM (e.g. the one in gold-plugin.cpp).

xur updated this revision to Diff 237810.Jan 13 2020, 4:20 PM

Thanks Teresa for the suggestion: using the print() function in the llvm diagnosticPrinter is a lot better than duplicating the code. I changed the patch to use print() function. Also added comment as suggested by Teresa.

tejohnson accepted this revision.Jan 13 2020, 4:44 PM

LGTM. One more request for a comment below that I forgot to add earlier.

clang/lib/CodeGen/CodeGenAction.cpp
154

Add comment as to what specific case this new constructor is for.

This revision is now accepted and ready to land.Jan 13 2020, 4:44 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJan 14 2020, 3:52 PM

This change triggers a crash in a release build of llvm:
See https://bugs.llvm.org/show_bug.cgi?id=44896