diff options
author | Jordan Rose <jordan_rose@apple.com> | 2012-08-10 22:26:29 +0000 |
---|---|---|
committer | Jordan Rose <jordan_rose@apple.com> | 2012-08-10 22:26:29 +0000 |
commit | 13937b1d7a730111b61355b74674a42f8901c2f5 (patch) | |
tree | f1d934c6d193d7e8f77dc33168b1e1c3a33568fb /llvm/lib/CodeGen/MachineTraceMetrics.cpp | |
parent | 29622c1f0be849b9e29d48eb5eb75e992247adfc (diff) | |
download | llvm-13937b1d7a730111b61355b74674a42f8901c2f5.zip llvm-13937b1d7a730111b61355b74674a42f8901c2f5.tar.gz llvm-13937b1d7a730111b61355b74674a42f8901c2f5.tar.bz2 |
[analyzer] Add clang_analyzer_checkInlined for debugging purposes.
This check is also accessible through the debug.ExprInspection checker.
Like clang_analyzer_eval, you can use it to test the analyzer engine's
current state; the argument should be true or false to indicate whether or
not you expect the function to be inlined.
When used in the positive case (clang_analyzer_checkInlined(true)), the
analyzer prints the message "TRUE" if the function is ever inlined. However,
clang_analyzer_checkInlined(false) should never print a message; this asserts
that there should be no paths on which the current function is inlined, but
then there are no paths on which to print a message! (If the assertion is
violated, the message "FALSE" will be printed.)
This asymmetry comes from the fact that the only other chance to print a
message is when the function is analyzed as a top-level function. However,
when we do that, we can't be sure it isn't also inlined elsewhere (such as
in a recursive function, or if we want to analyze in both general or
specialized cases). Rather than have all checkInlined calls have an appended,
meaningless "FALSE" or "TOP-LEVEL" case, there is just no message printed.
void clang_analyzer_checkInlined(int);
For debugging purposes only!
llvm-svn: 161708
Diffstat (limited to 'llvm/lib/CodeGen/MachineTraceMetrics.cpp')
0 files changed, 0 insertions, 0 deletions