Add extra early memcpyopt pass #22049
Conversation
Under certain circumstances, we emit loads/stores of large LLVM structs. A lot of these can be trivially folded to memcpy and memcpyopt is capable of doing so, but we weren't running it until after SROA. SROA unfortunately, likes to take these apart, causing exponential compile-time blow up and reduced runtime peroformance. In one particular case (2000 element tuple), this change results in a 100x improvement in compile time.
|
Could this PR be the reason for Nullable regressions in the latest daily benchmark? |
|
Really should have run nanosoldier here when it is a PR that explicitly deals with performance. |
|
Confirmed to have been this change. It's a bug in the loop vectorizer's cost model. However, the issue is resolved on LLVM master. Since we're not gonna release 0.7 before upgrading LLVM, I think we're fine. |
|
Any link to the bug fix on LLVM master? |
|
Haven't tracked down the exact commit. If you really care I'll run a bisect. |
|
Just wondering if it's clean enough to be backported to 3.9/4.0. A bisect would be cool but no hurry. |
|
Bisect running |
|
Bisect claims llvm-mirror/llvm@371d289, but it found a different commit the first time I ran it, so I think whether this vectorizes or not has been going back and forth a bit. |
Under certain circumstances, we emit loads/stores of large LLVM
structs. A lot of these can be trivially folded to memcpy and memcpyopt
is capable of doing so, but we weren't running it until after SROA.
SROA unfortunately, likes to take these apart, causing exponential
compile-time blow up and reduced runtime performance. In one particular
case (2000 element tuple), this change results in a 100x improvement
in compile time.