[cfe-dev] [analyzer][RFC] Get info from the LLVM IR for precision

Gábor Márton via cfe-dev cfe-dev at lists.llvm.org
Wed Aug 5 08:29:26 PDT 2020


Hi,

I have been working on a prototype that makes it possible to access the IR
from the components of the Clang Static Analyzer.
https://reviews.llvm.org/D85319

There are many important and useful analyses in the LLVM layer that we can
use during the path sensitive analysis. Most notably, the "readnone" and
"readonly" function attributes (https://llvm.org/docs/LangRef.html) which
can be used to identify "pure" functions (those without side effects). In
the prototype I am using the pureness info from the IR to avoid
invalidation of any variables during conservative evaluation (when we
evaluate a pure function). There are cases when we get false positives
exactly because of the too conservative invalidation.

Some further ideas to use info from the IR:
- We should invalidate only the arg regions for functions with "argmemonly"
attribute.
- Use the smarter invalidation in cross translation unit analysis too. We
can get the IR for the other TUs as well.
- Run the Attributor
<https://llvm.org/doxygen/structllvm_1_1Attributor.html> passes on the IR.
We could get range values for return values or for arguments. These range
values then could be fed to StdLibraryFunctionsChecker to make the proper
assumptions. And we could do this in CTU mode too, these attributes could
form some sort of a summary of these functions. Note that I don't expect a
meaningful summary for more than a few percent of all the available
functions.

Please let me know if you have any further ideas about how we could use IR
attributes (or anything else) during the symbolic execution.

There are some concerns as well. There may be some source code that we
cannot CodeGen, but we can still analyse with the current CSA. That is why
I suppress CodeGen diagnostics in the prototype. But in the worst case we
may run into assertions in the CodeGen and this may cause regression in the
whole analysis experience. This may be the case especially when we get a
compile_commands.json from a project that is compiled only with e.g. GCC.

Thanks,
Gabor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200805/f1119604/attachment.html>


More information about the cfe-dev mailing list