> One particular issue we fixed a couple of times in TigerBeetle is replacing by-value with by-pointer loops:<p>I don't know about other tools and places, but one nice thing about working at Facebook is the internal Infer linter tool[1] is generally good about producing warnings for "this copy could be a ref instead"[2] (in the majority C++ codebase) at code review time, without manually combing the LLVM IR for memcpys. (Internally, Infer is using several handwritten analyses on C++ AST.)<p>Reading further, it seems like they are essentially looking for the pattern where a memcpy call is generated with a large constant size parameter at compile time. Things of this nature <i>should</i> be somewhat easy to write a static analyzer pass for, if you've got an existing AST/SSA level framework. I believe there is already an Infer pass for this for C++, but it might be a different internal analyzer.<p>[1]: <a href="https://fbinfer.com/" rel="nofollow noreferrer">https://fbinfer.com/</a><p>[2]: <a href="https://github.com/facebook/infer/blob/main/infer/documentation/issues/PULSE_UNNECESSARY_COPY.md">https://github.com/facebook/infer/blob/main/infer/documentat...</a> (and related warnings, e.g., <a href="https://github.com/facebook/infer/blob/main/infer/documentation/issues/PULSE_CONST_REFABLE.md">https://github.com/facebook/infer/blob/main/infer/documentat...</a> )
Related: this pull request that was merged last night: <a href="https://github.com/ziglang/zig/pull/16558">https://github.com/ziglang/zig/pull/16558</a><p>Currently only enabled for debug builds of the compiler, but there's talk there about making it a more general purpose tool for finding where the costly generic function instantations are.
Man, I want to work at TigerBeetle so bad. So much cool stuff comes out of that company, exactly the type of stuff that I love thinking about and working on.<p>On a semi-related note, if you want to look into compiler backends/IRs, there's QBE[0], which is far simpler than LLVM IR, but gets most of the point across<p>[0]: <a href="https://c9x.me/compile/" rel="nofollow noreferrer">https://c9x.me/compile/</a>
By the way, if you're in the Amsterdam area next week, almost the whole TigerBeetle team will be there on Monday/Tuesday.<p>We'll be hosting a happy hour on Tuesday August 1st at 5pm. If you'd like to join, RSVP below and you're invited! Among others, some friends from the Zig communities will be coming through, and a DuckDB developer or two may be there. :)<p><a href="https://tigerbeetle.com/amsterdam23/" rel="nofollow noreferrer">https://tigerbeetle.com/amsterdam23/</a>
I've also written something like this: <a href="https://github.com/jrmuizel/memcpy-find">https://github.com/jrmuizel/memcpy-find</a><p>It uses debug info to get a full stack including inline information which is especially helpful when running on Rust code.
This would be a bad thing.<p>It's taking code written in terms of value semantics, copying stuff around, and replacing it with more efficient code that avoids the copy.<p>Doing that by improving the compiler is a win. Doing it by changing the source to be easier to compile is a loss. You're trading readability for performance when instead you should fix the compiler and get both.
> shaves off 300 bytes from the release binary<p>I wonder if it should be "kilobytes", 300 bytes are nothing considering that fs block size is usually 4KB.