LLVM: Memcpy-memcpy dependence isn't detected across basic blocks

[bstrie]

Last year, pcwalton submitted an LLVM patch that eliminates 30% of the memcpys in rustc: https://reviews.llvm.org/D23470 , which stagnated during review.

This year someone (whose Github nick I don't know) has revived the patch, which is still under review and whose likelihood of being merged is unclear to me: https://reviews.llvm.org/D38374

The purpose of this bug is to remind us that this patch exists, in case it remains stuck in limbo.

[pcwalton]

Not to rain on anyone's parade, but just for the record: Someone should redo the analysis to see how many memcpys are removed. Lots has changed in rustc and LLVM since that patch was submitted. I am not sure that that number is still valid.

[sunfishcode]

I have a current compiler built with the patch, and in a variety of Rust codebases it removes 20-30% of llvm.memcpys.

I haven't seen this contribute to a significant code size decrease or speedup yet, though I haven't looked at very many cases yet. The patch is interesting to me because:

• I've started looking at the generated code from Rust, and I often see more inline memcpy sequences than I'm accustomed to. They're not always measurable problems, but it feels like they distract from more interesting problems.
• It's a first step to potentially more interesting things. It suggests there are probably opportunities to eliminate even more @llvm.memcpy calls after this, perhaps with more work in MemCpyOpt, or perhaps MIR-level optimization can help.
• We could probably find speedups out there, if we look for them.

[dotdash]

FWIW the patch seems to have landed upstream.

[sunfishcode]

Yes, though it appears to have exposed an existing bug: https://bugs.llvm.org/show_bug.cgi?id=35519.

[bstrie]

Fantastic! I'll leave this open until rustc updates its version of LLVM to contain the patch and the new bugfix, so that we can make sure that the optimization survives integration.

[sunfishcode]

Update: the patch was reverted because it exposed some bugs, I fixed the bugs and relanded the patch, and it appears to have exposed more bugs, and it's been reverted again. It's become clear that this is a much riskier patch than it appeared. I don't currently know if I'm going to continue to pursue it.

One bit of optimism is that the MemDep framework that the code currently uses is expected to be replaced by the new MemorySSA framework some day, which is expected to make the optimization discussed here much simpler.

[bstrie]

One bit of optimism is that the MemDep framework that the code currently uses is expected to be replaced by the new MemorySSA framework some day, which is expected to make the optimization discussed here much simpler.

@sunfishcode , care to give a yearly update on LLVM's progress here? :) Alternatively, if you think this issue is no longer relevant I would be open to closing it.

[sunfishcode]

I have not continued to pursue this, myself. And, it looks like the new GVN framework based on MemorySSA is not yet enabled by default.

[nikic]

New attempt at https://reviews.llvm.org/D89207.