Workload</th>	Cache off</th>	Primed cache</th></tr></thead>
nghttp2 C</td>	1.84×</td>	1.61×</td></tr>
nghttp2 C++</td>	1.83×</td>	1.20×</td></tr>
Quiche</td>	1.59×</td>	1.50×</td></tr> </tbody></table> The cache avoids repeated C/C++ bitcode compilation, but still preprocesses and hashes current inputs before declaring a hit. It does not cache Rust compilation. The measurements also had an uncontrolled filesystem cache and normal desktop activity, so they are evidence for these workloads rather than a universal ratio. They compare `rllvm</code> with native builds, not with gllvm</code> or wllvm</code>.</p>` </i></a> The lineage now has a fork</h2> wllvm</code>, gllvm</code>, and rllvm</code> still share the same good trick: record sidecar bitcode paths in object files and let the linker accumulate them. The older tools center their interface on extracting a merged module or archive. rllvm</code> now keeps that workflow while adding another acquisition path and a representation between capture and merge.</p> That does not make it a strict superset. gllvm</code> supports Fortran and thin archives; wllvm</code> can drive GCC through dragonegg. But for Clang-based program analysis, rllvm</code> now exposes a much larger surface: Rust, WebAssembly and eBPF, real LTO extraction, relocatable paths, validated caching, module catalogs, selection, and compilation-database imports.</p> The meaningful difference is no longer implementation language or wrapper speed. It is where the tool stops. The older workflow stops when it produces bitcode. rllvm</code> is starting to preserve the structure that the next tool will need.</p> </i></a> What comes next</h2> My previous post</a> ended with a query interface for coding assistants: definitions, callers, callees, reachability, possible indirect targets, and an inspectable path back to source. The roadmap now gives that idea a clearer shape.</p> The first step is to make program facts easy to ask for. Scripts and coding assistants should be able to query a catalog in source-level terms and receive the locations and paths that support each answer. Missing modules, unresolved calls, and unavailable mappings should remain visible rather than turning into false certainty.</p> The second is to make the ask, edit, rebuild, ask loop practical. Unchanged work should be reused without letting an answer from an older build appear current. From there, simple reachability can grow into deeper security evidence when a question needs it, and program facts can be compared across revisions or build configurations. The useful result is still evidence a person can inspect, not an automatic verdict.</p> The final direction is broader reach: following calls across Rust and C/C++ boundaries, and carrying a verified analysis snapshot to another machine after the original build tree is gone.</p> The progression is from artifacts, to facts, to evidence. Extraction was the prerequisite. The catalog is the substrate that keeps every later answer tied to what was actually analyzed and what remains unknown.</p> rllvm</code> is Apache-2.0 and available on GitHub</a>. The repository includes the catalog schema</a> and benchmark evidence</a>.</p>

nghttp2 C</td>

1.84×</td>

1.61×</td></tr>

nghttp2 C++</td>

1.83×</td>

1.20×</td></tr>

Quiche</td>

1.59×</td>

1.50×</td></tr> </tbody></table>

The cache avoids repeated C/C++ bitcode compilation, but still preprocesses and hashes current inputs before declaring a hit. It does not cache Rust compilation. The measurements also had an uncontrolled filesystem cache and normal desktop activity, so they are evidence for these workloads rather than a universal ratio. They compare rllvm</code> with native builds, not with gllvm</code> or wllvm</code>.</p>

</i></a> The lineage now has a fork</h2> wllvm</code>, gllvm</code>, and rllvm</code> still share the same good trick: record sidecar bitcode paths in object files and let the linker accumulate them. The older tools center their interface on extracting a merged module or archive. rllvm</code> now keeps that workflow while adding another acquisition path and a representation between capture and merge.</p> That does not make it a strict superset. gllvm</code> supports Fortran and thin archives; wllvm</code> can drive GCC through dragonegg. But for Clang-based program analysis, rllvm</code> now exposes a much larger surface: Rust, WebAssembly and eBPF, real LTO extraction, relocatable paths, validated caching, module catalogs, selection, and compilation-database imports.</p> The meaningful difference is no longer implementation language or wrapper speed. It is where the tool stops. The older workflow stops when it produces bitcode. rllvm</code> is starting to preserve the structure that the next tool will need.</p> </i></a> What comes next</h2> My previous post</a> ended with a query interface for coding assistants: definitions, callers, callees, reachability, possible indirect targets, and an inspectable path back to source. The roadmap now gives that idea a clearer shape.</p> The first step is to make program facts easy to ask for. Scripts and coding assistants should be able to query a catalog in source-level terms and receive the locations and paths that support each answer. Missing modules, unresolved calls, and unavailable mappings should remain visible rather than turning into false certainty.</p> The second is to make the ask, edit, rebuild, ask loop practical. Unchanged work should be reused without letting an answer from an older build appear current. From there, simple reachability can grow into deeper security evidence when a question needs it, and program facts can be compared across revisions or build configurations. The useful result is still evidence a person can inspect, not an automatic verdict.</p> The final direction is broader reach: following calls across Rust and C/C++ boundaries, and carrying a verified analysis snapshot to another machine after the original build tree is gone.</p> The progression is from artifacts, to facts, to evidence. Extraction was the prerequisite. The catalog is the substrate that keeps every later answer tied to what was actually analyzed and what remains unknown.</p> rllvm</code> is Apache-2.0 and available on GitHub</a>. The repository includes the catalog schema</a> and benchmark evidence</a>.</p>

nu1lptr - Static Analysis

Beyond a Single Bitcode File