This is an archive of the discontinued LLVM Phabricator instance.

[CTU] Add support for virtual functions
ClosedPublic

Authored by martong on Jun 28 2019, 1:12 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

martong created this revision.Jun 28 2019, 1:12 AM
martong marked an inline comment as done.Jun 28 2019, 1:17 AM
martong added inline comments.
clang/test/Analysis/ctu-main.cpp
112 ↗(On Diff #207012)

In case you wonder why we don't use expected-warning{{UNKNOWN}} then please refer to this non-ctu bug report about virtual functions:
https://bugs.llvm.org/show_bug.cgi?id=42423

Try to set analyzer option IPAMode to something different from its default value which is dynamic-bifurcate in the test file.

martong updated this revision to Diff 207738.Jul 3 2019, 2:51 AM
  • Use -analyzer-config ipa=inlining in the test

Try to set analyzer option IPAMode to something different from its default value which is dynamic-bifurcate in the test file.

Ok I set it to ipa=inlining and then we receive the expected "UNKNOWN" warning.

Try to set analyzer option IPAMode to something different from its default value which is dynamic-bifurcate in the test file.

Ok I set it to ipa=inlining and then we receive the expected "UNKNOWN" warning.

Alright, what are testing here exactly? I think its fine to see how the new virtual functions are inlined in different inlining mode, but we should definitely have a RUN: line/test file with the default mode.

Try to set analyzer option IPAMode to something different from its default value which is dynamic-bifurcate in the test file.

Ok I set it to ipa=inlining and then we receive the expected "UNKNOWN" warning.

Alright, what are testing here exactly? I think its fine to see how the new virtual functions are inlined in different inlining mode, but we should definitely have a RUN: line/test file with the default mode.

So, we would like to have a test which indicates that we can inline a virtual function from another TU. These tests are at line 110 and 111.

At line 113 we would like to have a test which verifies that if the dynamic type is unknown there is not much we can gain with inlining.
So, either we use the default ipa mode and then we will have

clang_analyzer_eval(obj->fvcl(1));           // expected-warning{{TRUE}} expected-warning{{UNKOWN}}

Or we use` ipa=inlining` and then we have

clang_analyzer_eval(obj->fvcl(1));           // expected-warning{{UNKOWN}}

The latter seems to be more meaningful for me because it is hard to explain why we expect {{TRUE}} in the first case.
Still I vote for a third alternative when we use the default ipa mode:

clang_analyzer_eval(obj->fvcl(1) == 8);           // expected-warning{{TRUE}} expected-warning{{FALSE}}

This seems to be clear for me , it is obvious from the warnings that the dynamic type is unknown.

Or perhaps there is no need to have a check for the case when the dynamic type is unknown?

So, we would like to have a test which indicates that we can inline a virtual function from another TU. These tests are at line 110 and 111.

At line 113 we would like to have a test which verifies that if the dynamic type is unknown there is not much we can gain with inlining.
So, either we use the default ipa mode and then we will have

clang_analyzer_eval(obj->fvcl(1));           // expected-warning{{TRUE}} expected-warning{{UNKOWN}}

Or we use` ipa=inlining` and then we have

clang_analyzer_eval(obj->fvcl(1));           // expected-warning{{UNKOWN}}

The latter seems to be more meaningful for me because it is hard to explain why we expect {{TRUE}} in the first case.
Still I vote for a third alternative when we use the default ipa mode:

clang_analyzer_eval(obj->fvcl(1) == 8);           // expected-warning{{TRUE}} expected-warning{{FALSE}}

This seems to be clear for me , it is obvious from the warnings that the dynamic type is unknown.

Or perhaps there is no need to have a check for the case when the dynamic type is unknown?

Okay, so changing the inlining mode for any other reason then a test case sounds like a super risky idea. I don't think we're going to change it for our use cases anytime soon. Could you please add a RUN: line where with default inlining?

martong updated this revision to Diff 208002.Jul 4 2019, 2:52 AM
  • Remove ipa mode from the test
This revision is now accepted and ready to land.Jul 4 2019, 2:55 AM

Thanks for the review!

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 4 2019, 4:38 AM