llvm-based tools vs. clang-based tools

"The Google compiler team has built a tool around LLVM that shows a novel use of the compiler toolkit. The tool looks for common problems that appear as certain patterns in the LLVM intermediate representation and can map them back to the C++ code to show the programmer where they made an error. This shows things that you can do that we haven't seen before, he said."

This paragraph is mixing two sorts of tools. There are tools based on the clang's ASTs which are normally static tools, such as the compiler warnings, the AST matchers and clang mapreduce. None of these involve matching on LLVM IR, rather, these work by matching patterns in your C++ code and can thus point to the problems in the written C++ code.

Then there are tools based on LLVM IR which are (so far) all dynamic tools, address/thread/memory sanitizer, but they don't really map back to C++ code. They produce reports similar to valgrind.

We don't have any tools that match patterns in LLVM IR and then point out bugs in the C++ code. You can match LLVM IR and point out bugs in the final binary, or you can match clang ASTs and point out bugs in the incoming source code. Trying to go from LLVM IR back up to the original C++ code is hard, not designed for, and we don't do it. (In essence, you're relying on the correctness of optimized debug info, which LLVM doesn't do yet.)